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

[John Hubbard <jhubbard@nvidia.com>]

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.

thanks,
-- 
John Hubbard