-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Make sure arenas don't allocate bigger than HUGE_PAGE #78058
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
Conversation
r? @lcnr (rust_highfive has picked a reviewer for you, use r? to override) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you expect this changes to have an influence on perf?
Hard to say, I lean on "not really". Shouldn't degrade perf, at least. |
this code is really hot, so it's better to be safe here @bors try @rust-timer queue |
Awaiting bors try build completion |
⌛ Trying commit 396561b with merge e270068a34bb00af7da331d9029c3b5ce2dad3d3... |
☀️ Try build successful - checks-actions, checks-azure |
Queued e270068a34bb00af7da331d9029c3b5ce2dad3d3 with parent ffeeb20, future comparison URL. |
Finished benchmarking try commit (e270068a34bb00af7da331d9029c3b5ce2dad3d3): comparison url. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up. @bors rollup=never |
Looks like no impact. |
well, then @bors r+ rollup |
📌 Commit 396561b has been approved by |
☀️ Test successful - checks-actions, checks-azure |
Right now, arenas allocate based on the size of the last chunk. It is possible for a
grow
call to allocate a chunk that is not a multiple ofPAGE
, and this size is doubled for each subsequent allocation. This means, instead ofHUGE_PAGE
, the biggest page possible is actually unknown.This change fixes this, and also removes an unnecessary checked multiplication. It is still possible to allocate bigger than
HUGE_PAGE
pages, but this will only happen as many times as absolutely necessary.