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
