Re: [PATCH] gpu: nova-core: add ChannelIdPool

[Gary Guo]

On Sat Jul 11, 2026 at 1:28 PM BST, Alice Ryhl wrote:
> On Fri, Jul 10, 2026 at 02:29:39PM -0700, John Hubbard wrote:
>> On 7/10/26 6:42 AM, Eliot Courtney wrote:
>> ...
>> > +use kernel::{
>> > +    maple_tree::MapleTreeAlloc,
>> 
>> Hi Eliot, Alice, all,
>> 
>> Eliot already laid out the maple costs (the alloc_range+erase loop
>> replicating find_next_zero_area, the extra mutex, allocation on
>> alloc and free), so I won't rehash them. What I can add is why the
>> alignment is a hard requirement, since that is what seems to make
>> the decision clearer to me at least.
>> 
>> Pre-Blackwell, USERD sits in BAR1 at page granularity, 8 channels to a
>> 4K page (chid = page*8 + slot). Giving a VM its own channels means
>> giving it whole USERD pages, so a VM's chid range has to be 8-aligned
>> and a multiple of 8. Blackwell moves submit to a per-function doorbell
>> keyed by (runlist, chid), and the constraint goes away. So it's a
>> constraint we're stuck with pre-Blackwell, not one we can design away.
>> 
>> Given that, the bitmap version is hard to argue with. The aligned
>> allocation is the one call the API is built around, roughly:
>> 
>>     let mut ids = self.inner.lock();
>>     let area = ids.find_unused_area(0, count, align_mask)
>>                   .ok_or(ENOSPC)?;
>>     // area.acquire() reserves and returns the range, drop clears it
>> 
>> One lock, no retry, and release is a bitmap_clear that can't fail. For
>> 2048 IDs the backing store is a 256-byte array. find_next_zero_area()
>> is also the existing idiom for this (IOMMU, DMA, IRQ), so it answers
>> Greg's reuse-what-exists point as well.
>> 
>> I'd go with the bitmap id_pool.
>
> Completely agreed. The loop in this patch seems like a really bad idea
> to me. If the maple tree doesn't natively provide a way to allocate the
> range with an alignment requirement, we should not attempt to hack in
> support for alignment by looping. Please use the bitmap.
>
> (Even without the alignment requirement, I think that the 2048 size
> limit is also a good reason to use a bitmap, but the argument is less
> strong in that case.)

I think the reasoning is strong, you get everything fit within 4 cache lines and
with even a dumb prefetcher you'd have no more than 2 cache misses . It's going
to be faster than data structures that need indirection.

Best,
Gary