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

[Alice Ryhl]

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.)

Alice