SFBdragon
Support fallible malloc attempts without OOM handling
When allocating with Talc for a balloon device allocations should be multiples of 4KiB in size and must be aligned to 4KiB. To reduce per-allocation overhead we want to group such allocations as much as possible into large chunks. Allocation of such almost as large as possible chunks below a maximum size can be accomplished by attempting allocations in decreasing powers of two below the maximum size. These allocation attempts would however trigger the OOM handler which is undesirable. The balloon driver is also responsible for OOM handling in my case and since we are already within balloon driver code, making these allocation attempts, the driver is already locked. The OOM handler therefore cannot (and should not) deflate the balloon, because the driver state is locked. Thus we want to be able to make allocation attempts without triggering the OOM handler.
This includes a drive-by fix for the derived Hash impl conflicting with the explicit PartialEq implementation of Span. They differed on equality for empty Spans AFAICT.
Hey, thanks for the PR!
Both of these changes seem good to me. I'll likely merge them soon and port them forward to the next relelase I've been working on.
I was wondering: instead of scanning for decreasing powers of two, it's possible for Talc to quickly find it's largest available chunk and allocate it. There just isn't an API or implementation for it, but it could be easily added. Though Talc can reject requests for sizes considerably larger than it has very quickly (handful of instructions... iirc, been a while since I worked on V4).
Would this fit your needs better?
-------- Original Message -------- On 2025/08/27 20:50, Hans Christian Schmitz wrote:
When allocating with Talc for a balloon device allocations should be multiples of 4KiB in size and must be aligned to 4KiB. To reduce per-allocation overhead we want to group such allocations as much as possible into large chunks. Allocation of such almost as large as possible chunks below a maximum size can be accomplished by attempting allocations in decreasing powers of two below the maximum size. These allocation attempts would however trigger the OOM handler which is undesirable. The balloon driver is also responsible for OOM handling in my case and since we are already within balloon driver code, making these allocation attempts, the driver is already locked. The OOM handler therefore cannot (and should not) deflate the balloon, because the driver state is locked. Thus we want to be able to make allocation attempts without triggering the OOM handler.
This includes a drive-by fix for the derived Hash impl conflicting with the explicit PartialEq implementation of Span. They differed on equality for empty Spans AFAICT.
You can view, comment on, or merge this pull request online at:
https://github.com/SFBdragon/talc/pull/43
Commit Summary
- b3c0312 Fix derived
Hashfor type with customPartialEq- df18c6c Support fallible malloc attempts without OOM handling
File Changes
(2 files)
- M talc/src/span.rs (23)
- M talc/src/talc.rs (30)
Patch Links:
- https://github.com/SFBdragon/talc/pull/43.patch
- https://github.com/SFBdragon/talc/pull/43.diff
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>
Hey, thanks for the positive response :D
Being able to query Talc for the largest still possible contiguous allocation would be great as well, and IMO even feels a bit cleaner.
I wrote this change to Talc in the process of my bachelor's thesis so I was a bit limited in time for delving into how talc does things, which is why I picked the current approach.
Just noticed that I still had the old try_malloc name in a doc comment. I fixed that to use the malloc_without_oom_handler name in the force push just now.