-
Notifications
You must be signed in to change notification settings - Fork 112
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
Make smallbuddy handle larger requests correctly #556
Conversation
@@ -204,7 +213,8 @@ namespace snmalloc | |||
|
|||
CapPtr<void, ChunkBounds> alloc_range(size_t size) | |||
{ | |||
SNMALLOC_ASSERT(size < MIN_CHUNK_SIZE); | |||
if (size >= MIN_CHUNK_SIZE) | |||
return parent.alloc_range(size); |
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.
I recall us going back and forth on this previously, with the idea that the caller should skip the SmallBuddy
ranges if they needed something larger. This fallback requires that the return type of the SmallBuddy
match that of its parent, which might not, in general, be true: while a LargeBuddy
"must" operate on CapPtr
s intended to be large enough to include whole PageMap
MetaEntry
s worth of space, as it uses those for its metadata, the SmallBuddy
, which uses in-band metadata, could have more tightly bounded types.
I suppose we're not actually taking advantage of that right now, tho'... but is there reason not to ask for the Range's parent
in the caller instead?
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.
So ultimately we need a branch somewhere in alloc_meta_data
. This would need to determine how large the request is and then which range to send it too. The code in SmallBuddyRange::alloc_with_leftover
, returns the slop at the end of the allocation. This could be useful for large meta data allocations as well as small, so might want to be duplicated, though not essential.
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.
Following Teams call, I have added a test to ensure future changes don't break the Verona use case.
We will leave this design as is, but will revisit after @nwf-msr investigates a fine granularity of permissions.
c1fa6a7
to
2b8f50c
Compare
2b8f50c
to
d69f9ca
Compare
This commit makes the rounding and the bounding occur in the same function.
The smallbuddy can now pass the larger requests up the range chain if it cannot satisfy it itself.
d69f9ca
to
fcc3baf
Compare
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.
LGTM
* Fail more abruptly if the bounds are not exact. * Move bounding from Pool into Backend. This commit makes the rounding and the bounding occur in the same function. * Enable smallbuddyrange to handle larger requests The smallbuddy can now pass the larger requests up the range chain if it cannot satisfy it itself. * Test larger requests for meta-data.
Verona was using a pool allocator to requests large pieces of meta-data. This was broken with the current design, so the smallbuddy can now pass requests up if they are too large.