Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix slow IsCheckpointImage making podman run slow #16068

Closed

Conversation

alexlarsson
Copy link
Contributor

@alexlarsson alexlarsson commented Oct 6, 2022

IsCheckpointImage() currently calls registry.ContainerEngine().Info(ctx) in order to get the name of the oci runtime. However, this call is very slow, as it collects all sort of other (unnecessary) information.

In addition, this returns the default oci runtime, and really it seems to be more correct here to use the currently-in-use oci runtime.

So, we switch to getting the oci runtime name via:
registry.PodmanConfig().RuntimePath

This seems to return the same value, and is much faster. The actual runtime is highly variable, so I'm taking the fastest run of 20 as a measure.

Before this change:

$ time ./bin/podman run fedora true
real 0m0,556s
user 0m0,155s
sys 0m0,090s

After the change:
$ time ./bin/podman run fedora true
real 0m0,456s
user 0m0,101s
sys 0m0,042s

So, this seems to be about a 100msec performance improvement.

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Oct 6, 2022

@alexlarsson: Adding the "do-not-merge/release-note-label-needed" label because no release-note block was detected, please follow our release note process to remove it.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@openshift-ci openshift-ci bot added the do-not-merge/release-note-label-needed Enforce release-note requirement, even if just None label Oct 6, 2022
@alexlarsson alexlarsson force-pushed the fix-slow-ischeckpointimage branch from 5f8c5d8 to 99fc9af Compare October 6, 2022 09:21
Copy link
Member

@giuseppe giuseppe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Oct 6, 2022

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: alexlarsson, giuseppe

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Oct 6, 2022
@rhatdan rhatdan removed the do-not-merge/release-note-label-needed Enforce release-note requirement, even if just None label Oct 6, 2022
@rhatdan
Copy link
Member

rhatdan commented Oct 6, 2022

I think this is correct, although I am worried about podman-remote versus podman. Since I think this is only getting the OCI Runtime from the client. I am not sure if this runtime is sent to the server side. Calling info for this information does seem to be way overkill though.

@mheon PTAL

@rhatdan
Copy link
Member

rhatdan commented Oct 6, 2022

I now believe this function should be called on the server side not on the client side anyways.

@rhatdan
Copy link
Member

rhatdan commented Oct 6, 2022

@rst0git PTAL

cmd/podman/utils/utils.go Outdated Show resolved Hide resolved
@alexlarsson alexlarsson force-pushed the fix-slow-ischeckpointimage branch from 99fc9af to 7c12081 Compare October 6, 2022 11:53
IsCheckpointImage() currently calls registry.ContainerEngine().Info(ctx)
in order to get the name of the oci runtime. However, this call is very
slow, as it collects all sort of other (unnecessary) information.

In addition, this returns the *default* oci runtime, and really it seems
to be more correct here to use the *currently-in-use* oci runtime.

So, we switch to getting the oci runtime name via:
 registry.PodmanConfig().RuntimePath

This seems to return the same value, and is much faster. The actual
runtime is highly variable, so I'm taking the fastest run of 20 as
a measure.

Before this change:

$ time  ./bin/podman run  fedora true
real	0m0,556s
user	0m0,155s
sys	0m0,090s

After the change:
$ time  ./bin/podman run  fedora true
real	0m0,456s
user	0m0,101s
sys	0m0,042s

So, this seems to be about a 100msec performance improvement.

Signed-off-by: Alexander Larsson <[email protected]>
@alexlarsson alexlarsson force-pushed the fix-slow-ischeckpointimage branch from 7c12081 to e0d8d3b Compare October 6, 2022 11:54
@mheon
Copy link
Member

mheon commented Oct 6, 2022

You need to add [NO NEW TESTS NEEDED] to your commit message to make CI happy.

if err != nil {
return false, err
}
runtimeName := filepath.Base(registry.PodmanConfig().RuntimePath)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

RuntimePath is legacy at this point - you want OCIRuntime. It should already be the name of the runtime as used by Podman, not a path that needs to be trimmed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would OCIRuntime be set to the value specified with --runtime when it is used?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure what you mean. How would i get the OCIRuntime.
For the name, here is what we currently get by default:

hostinfo.OCIRuntime.Name: crun
registry.PodmanConfig().RuntimePath: crun

And with --runtime runc:
hostinfo.OCIRuntime.Name: runc
registry.PodmanConfig().RuntimePath: runc

And with --runtime /usr/bin/crun
hostinfo.OCIRuntime.Name: /usr/bin/crun
registry.PodmanConfig().RuntimePath: /usr/bin/crun

Given the above it seems like the current/old code (using hostinfo) doesn't apply filepath.Base(). Does that mean it is wrong?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That doesn't seem to give the right thing though.

If I use registry.PodmanConfig().Engine.OCIRuntime, then by default that contains crun which is fine.

However if i run podman run --runtime=runc, it still contains crun, which strikes me as wrong.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can't get that from the config... You'd need to grab Libpod's DefaultOCIRuntime to know that.

If RuntimePath in the config is actually reflecting that, that's a bug, not intended behavior.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, this probably doesn't work properly for podman-remote as implemented, now that I think about it... You'll get the config from the client, not the server.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is what I said above, this needs to be checked on the server side not the client.

Copy link
Contributor

@rst0git rst0git left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM
@alexlarsson Thank you for fixing this!

@rhatdan
Copy link
Member

rhatdan commented Oct 6, 2022

I believe the original patch for checkpoint needs to be reverted, I opened a PR to do this and will close this PR.

@rhatdan rhatdan closed this Oct 6, 2022
@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 20, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 20, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants