Update rust toolchain to 1.68.2 #3576
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Update rust toolchain from 1.66.1 to 1.68.2 Signed-off-by: Patrick Roy <roypat@amazon.co.uk>
- The `Default` trait can now be derived - Lifetime elision got more sophisticated Signed-off-by: Patrick Roy <roypat@amazon.co.uk>
Signed-off-by: Patrick Roy <roypat@amazon.co.uk>
With rust 1.67.0, the implementation for std::sync::mpmc (which we transitively use through using mpsc channels) got switched out for crossbeam's implementation, which includes a `sched_yield` syscall [1]. [1]: https://github.com/rust-lang/rust/blame/cf32b9de1e8f66526c36ad2927458558d2e81093/library/std/src/sync/mpmc/utils.rs#L130 Signed-off-by: Patrick Roy <roypat@amazon.co.uk>
9 tasks
|
All the changes from these commits are required to pass CI, as a result of the rust update, I think it would make sense in this case for these to all be in 1 commit, so we minimize commits which don't pass CI. |
pb8o
reviewed
Mar 30, 2023
pb8o
approved these changes
Mar 30, 2023
9 tasks
roypat
added
the
Status: Awaiting review
I don't think we want to go that way. We currently do not ensure that all commits pass CI (see code coverage changes, binary size changes, etc.). Also, I see value in having these changes in different commits. It is much easier to review and identify issues later on. |
ah whoops, missed this earlier. I agree with Babis here. Having it broken into logical pieces makes cherry-picking/backporting a lot easier. For example, the coverage adjustment is different for every release branch, but the seccomp changes applied cleanly to all of them. With clippy, there was no knowing if I could cherry-pick from here (which I could), or whether old branches would need different patches. |
JonathanWoollett-Light
approved these changes
Mar 31, 2023
roypat
added a commit
to roypat/firecracker
that referenced
this pull request
Apr 13, 2023
The test calls the `serve_vmm_action_request` function and tries to check whether it correctly updates specific metrices related to measuring how long a request took. However, since the VMM side is mocked out in this test (the receiver end of the channel through which the API server communicates is simply pre-filled with VmmData::Empty, and not passed to any implementation that handles the requests), the `serve_vmm_action_request` function only goes through the following steps: 1. Put something into a channel 2. Read a pre-submitted value from another channel 3. Update the metrics This can happen very fast (below 1us, which is the resolution of our metrics), in which cases the unittests fails at the assertion that tries to check whether the metric of "how long did handling this request take" was correctly set (as this assertion only checks that the metric is not 0). I suspect that the reason we have been encountering this more often recently is due to the Rust 1.67.0 update (firecracker-microvm#3576), which replaced the old stdlib implementation of mpsc channels with that from the crossbeam crate. Since channel operations are most of what the test does, this could have a performance impact if the new rust version has a more performant implementation (which the changelog implies [1]). We fix this by subtracting 1 from the start time inside the test, so make sure that the difference "now - start time" which serve_vmm_action_request uses to compute the metric value is always at least 1. [1]: https://blog.rust-lang.org/2023/01/26/Rust-1.67.0.html Signed-off-by: Patrick Roy <roypat@amazon.co.uk>
zulinx86
pushed a commit
that referenced
this pull request
Apr 13, 2023
The test calls the `serve_vmm_action_request` function and tries to check whether it correctly updates specific metrices related to measuring how long a request took. However, since the VMM side is mocked out in this test (the receiver end of the channel through which the API server communicates is simply pre-filled with VmmData::Empty, and not passed to any implementation that handles the requests), the `serve_vmm_action_request` function only goes through the following steps: 1. Put something into a channel 2. Read a pre-submitted value from another channel 3. Update the metrics This can happen very fast (below 1us, which is the resolution of our metrics), in which cases the unittests fails at the assertion that tries to check whether the metric of "how long did handling this request take" was correctly set (as this assertion only checks that the metric is not 0). I suspect that the reason we have been encountering this more often recently is due to the Rust 1.67.0 update (#3576), which replaced the old stdlib implementation of mpsc channels with that from the crossbeam crate. Since channel operations are most of what the test does, this could have a performance impact if the new rust version has a more performant implementation (which the changelog implies [1]). We fix this by subtracting 1 from the start time inside the test, so make sure that the difference "now - start time" which serve_vmm_action_request uses to compute the metric value is always at least 1. [1]: https://blog.rust-lang.org/2023/01/26/Rust-1.67.0.html Signed-off-by: Patrick Roy <roypat@amazon.co.uk>
andreitraistaru
pushed a commit
to andreitraistaru/firecracker
that referenced
this pull request
Apr 26, 2023
The test calls the `serve_vmm_action_request` function and tries to check whether it correctly updates specific metrices related to measuring how long a request took. However, since the VMM side is mocked out in this test (the receiver end of the channel through which the API server communicates is simply pre-filled with VmmData::Empty, and not passed to any implementation that handles the requests), the `serve_vmm_action_request` function only goes through the following steps: 1. Put something into a channel 2. Read a pre-submitted value from another channel 3. Update the metrics This can happen very fast (below 1us, which is the resolution of our metrics), in which cases the unittests fails at the assertion that tries to check whether the metric of "how long did handling this request take" was correctly set (as this assertion only checks that the metric is not 0). I suspect that the reason we have been encountering this more often recently is due to the Rust 1.67.0 update (firecracker-microvm#3576), which replaced the old stdlib implementation of mpsc channels with that from the crossbeam crate. Since channel operations are most of what the test does, this could have a performance impact if the new rust version has a more performant implementation (which the changelog implies [1]). We fix this by subtracting 1 from the start time inside the test, so make sure that the difference "now - start time" which serve_vmm_action_request uses to compute the metric value is always at least 1. [1]: https://blog.rust-lang.org/2023/01/26/Rust-1.67.0.html Signed-off-by: Patrick Roy <roypat@amazon.co.uk>
andreitraistaru
pushed a commit
to andreitraistaru/firecracker
that referenced
this pull request
Apr 26, 2023
The test calls the `serve_vmm_action_request` function and tries to check whether it correctly updates specific metrices related to measuring how long a request took. However, since the VMM side is mocked out in this test (the receiver end of the channel through which the API server communicates is simply pre-filled with VmmData::Empty, and not passed to any implementation that handles the requests), the `serve_vmm_action_request` function only goes through the following steps: 1. Put something into a channel 2. Read a pre-submitted value from another channel 3. Update the metrics This can happen very fast (below 1us, which is the resolution of our metrics), in which cases the unittests fails at the assertion that tries to check whether the metric of "how long did handling this request take" was correctly set (as this assertion only checks that the metric is not 0). I suspect that the reason we have been encountering this more often recently is due to the Rust 1.67.0 update (firecracker-microvm#3576), which replaced the old stdlib implementation of mpsc channels with that from the crossbeam crate. Since channel operations are most of what the test does, this could have a performance impact if the new rust version has a more performant implementation (which the changelog implies [1]). We fix this by subtracting 1 from the start time inside the test, so make sure that the difference "now - start time" which serve_vmm_action_request uses to compute the metric value is always at least 1. [1]: https://blog.rust-lang.org/2023/01/26/Rust-1.67.0.html Signed-off-by: Patrick Roy <roypat@amazon.co.uk>
andreitraistaru
pushed a commit
that referenced
this pull request
Apr 26, 2023
The test calls the `serve_vmm_action_request` function and tries to check whether it correctly updates specific metrices related to measuring how long a request took. However, since the VMM side is mocked out in this test (the receiver end of the channel through which the API server communicates is simply pre-filled with VmmData::Empty, and not passed to any implementation that handles the requests), the `serve_vmm_action_request` function only goes through the following steps: 1. Put something into a channel 2. Read a pre-submitted value from another channel 3. Update the metrics This can happen very fast (below 1us, which is the resolution of our metrics), in which cases the unittests fails at the assertion that tries to check whether the metric of "how long did handling this request take" was correctly set (as this assertion only checks that the metric is not 0). I suspect that the reason we have been encountering this more often recently is due to the Rust 1.67.0 update (#3576), which replaced the old stdlib implementation of mpsc channels with that from the crossbeam crate. Since channel operations are most of what the test does, this could have a performance impact if the new rust version has a more performant implementation (which the changelog implies [1]). We fix this by subtracting 1 from the start time inside the test, so make sure that the difference "now - start time" which serve_vmm_action_request uses to compute the metric value is always at least 1. [1]: https://blog.rust-lang.org/2023/01/26/Rust-1.67.0.html Signed-off-by: Patrick Roy <roypat@amazon.co.uk>
andreitraistaru
pushed a commit
that referenced
this pull request
Apr 26, 2023
The test calls the `serve_vmm_action_request` function and tries to check whether it correctly updates specific metrices related to measuring how long a request took. However, since the VMM side is mocked out in this test (the receiver end of the channel through which the API server communicates is simply pre-filled with VmmData::Empty, and not passed to any implementation that handles the requests), the `serve_vmm_action_request` function only goes through the following steps: 1. Put something into a channel 2. Read a pre-submitted value from another channel 3. Update the metrics This can happen very fast (below 1us, which is the resolution of our metrics), in which cases the unittests fails at the assertion that tries to check whether the metric of "how long did handling this request take" was correctly set (as this assertion only checks that the metric is not 0). I suspect that the reason we have been encountering this more often recently is due to the Rust 1.67.0 update (#3576), which replaced the old stdlib implementation of mpsc channels with that from the crossbeam crate. Since channel operations are most of what the test does, this could have a performance impact if the new rust version has a more performant implementation (which the changelog implies [1]). We fix this by subtracting 1 from the start time inside the test, so make sure that the difference "now - start time" which serve_vmm_action_request uses to compute the metric value is always at least 1. [1]: https://blog.rust-lang.org/2023/01/26/Rust-1.67.0.html Signed-off-by: Patrick Roy <roypat@amazon.co.uk>
sladyn98
pushed a commit
to sladyn98/firecracker
that referenced
this pull request
Jun 19, 2023
The test calls the `serve_vmm_action_request` function and tries to check whether it correctly updates specific metrices related to measuring how long a request took. However, since the VMM side is mocked out in this test (the receiver end of the channel through which the API server communicates is simply pre-filled with VmmData::Empty, and not passed to any implementation that handles the requests), the `serve_vmm_action_request` function only goes through the following steps: 1. Put something into a channel 2. Read a pre-submitted value from another channel 3. Update the metrics This can happen very fast (below 1us, which is the resolution of our metrics), in which cases the unittests fails at the assertion that tries to check whether the metric of "how long did handling this request take" was correctly set (as this assertion only checks that the metric is not 0). I suspect that the reason we have been encountering this more often recently is due to the Rust 1.67.0 update (firecracker-microvm#3576), which replaced the old stdlib implementation of mpsc channels with that from the crossbeam crate. Since channel operations are most of what the test does, this could have a performance impact if the new rust version has a more performant implementation (which the changelog implies [1]). We fix this by subtracting 1 from the start time inside the test, so make sure that the difference "now - start time" which serve_vmm_action_request uses to compute the metric value is always at least 1. [1]: https://blog.rust-lang.org/2023/01/26/Rust-1.67.0.html Signed-off-by: Patrick Roy <roypat@amazon.co.uk>
ShadowCurse
pushed a commit
to ShadowCurse/firecracker
that referenced
this pull request
Jul 26, 2023
The test calls the `serve_vmm_action_request` function and tries to check whether it correctly updates specific metrices related to measuring how long a request took. However, since the VMM side is mocked out in this test (the receiver end of the channel through which the API server communicates is simply pre-filled with VmmData::Empty, and not passed to any implementation that handles the requests), the `serve_vmm_action_request` function only goes through the following steps: 1. Put something into a channel 2. Read a pre-submitted value from another channel 3. Update the metrics This can happen very fast (below 1us, which is the resolution of our metrics), in which cases the unittests fails at the assertion that tries to check whether the metric of "how long did handling this request take" was correctly set (as this assertion only checks that the metric is not 0). I suspect that the reason we have been encountering this more often recently is due to the Rust 1.67.0 update (firecracker-microvm#3576), which replaced the old stdlib implementation of mpsc channels with that from the crossbeam crate. Since channel operations are most of what the test does, this could have a performance impact if the new rust version has a more performant implementation (which the changelog implies [1]). We fix this by subtracting 1 from the start time inside the test, so make sure that the difference "now - start time" which serve_vmm_action_request uses to compute the metric value is always at least 1. [1]: https://blog.rust-lang.org/2023/01/26/Rust-1.67.0.html Signed-off-by: Patrick Roy <roypat@amazon.co.uk>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Changes
Defaultimplementations and elidable lifetimessched_yieldto the seccomp allow list, as with 1.67.0, the rust standard library changed the backend formpmcchannels (which we use throughstd::sync::mpscfor inter-thread communication) to use crossbeams implementatation, which usessched_yieldas part of its spin-locking logic [1]Reason
backport of #3576
License Acceptance
By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache 2.0 license. For more information on following
Developer Certificate of Origin and signing off your commits, please check
CONTRIBUTING.md.PR Checklist
CHANGELOG.md.TODOs link to an issue.rust-vmm.