Support fallible malloc attempts without OOM handling

[hcsch]

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.

[SFBdragon]

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: #43 Commit Summary - [b3c0312](b3c0312) Fix derived `Hash` for type with custom `PartialEq` - [df18c6c](df18c6c) Support fallible malloc attempts without OOM handling File Changes ([2 files](https://github.com/SFBdragon/talc/pull/43/files)) - M [talc/src/span.rs](https://github.com/SFBdragon/talc/pull/43/files#diff-6cbdd489cd12405390eb955c5f2ba0f924858eebc2fe663a0286978f4752a4dc) (23) - M [talc/src/talc.rs](https://github.com/SFBdragon/talc/pull/43/files#diff-2473adf2aa35ff5879a705f9508f930e4b1d1b0c225400b8702ef419ffcd1ac4) (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](#43), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ALAPHRZL5CA4YQO7PP5MS233PX4Y3AVCNFSM6AAAAACE7CUSOSVHI2DSMVQWIX3LMV43ASLTON2WKOZTGM3DANJQG42DQNY). You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[hcsch]

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.

[hcsch]

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.

[SFBdragon]

try_allocate is now available in 5.0.0-beta.1.

I haven't implemented a function to get one/iterate available chunk sizes from the top down though yet. Should be easy to implement, and I'm happy to do it if it's still desirable.

Leaving this open for now.