On 3/16/2026 9:02 PM, Alexandre Courbot wrote:
> On Tue Mar 17, 2026 at 3:51 AM JST, John Hubbard wrote:
>> On 3/16/26 6:12 AM, Alexandre Courbot wrote:
>>> On Mon Mar 9, 2026 at 10:53 PM JST, Joel Fernandes wrote:
>> ...
>>>> +//! // Create a 1GB buddy allocator with 4KB minimum chunk size.
>>>> +//! let buddy = GpuBuddy::new(GpuBuddyParams {
>>>> +//! base_offset: 0,
>>>> +//! physical_memory_size: SZ_1G as u64,
>>>> +//! chunk_size: SZ_4K,
>>>
>>> `chunk_size` is an interesting case. The C API uses a `u64`, but I think
>>> we can reasonably consider that we won't ever need chunks larger than
>>> 4GB (or can we :O). I'm actually ok with using a `usize` for this one.
>>>
>>> One of the first things the C code does is throwing an error if it is
>>> not a power of 2, so maybe we can even request an `Alignment`?
>>>
>>> I'm a bit torn as to whether we should use a `u64` to conform with the C
>>> API, but doing so would mean we cannot use an `Alignment`...
>>
>> Alex, have you seen my Alignment patch [1], for that? It's sitting
>> around with only Miguel having responded, but seems like exactly
>> what you're talking about here.
>
> Not exactly - this patch provides a shortcut for creating an Alignment
> from a u64, but it doesn't allow to store alignments larger than 4GB on
> a 32-bit architecture since the value itself is still stored as a `usize`.
>
> But that's really a theoretical worry of mine anyway - nobody will ever
> work with buffers larger than 4GB on a 32-bit arch to begin with.
I think we don't have to worry about chunk size ever exceeding 4GB. Such a large
minimum size will cause massive fragmentation, essentially defeating the purpose
of a buddy allocator and not even for work for any VRAM with < 4GB memory
anyway.
Per Alex's other email, I will switch this to Alignment to constrain the
alignment requirement. I agree now that the robustness of doing so is worth it.
thanks,
--
Joel Fernandes
