Re: [PATCH 3/4] rust: id_pool: add contiguous area allocation

[Burak Emir <burak.emir@gmail.com>]

On Wed, Jul 8, 2026 at 11:08 PM Alice Ryhl <aliceryhl@google.com> wrote:
>
> On Wed, Jul 08, 2026 at 04:37:38PM -0400, Yury Norov wrote:
> > On Wed, Jul 08, 2026 at 07:33:16AM +0200, Greg KH wrote:
> >
> > ...
> >
> > > > I asked exactly the same question when Alice and Burak added wrappers
> > > > for bitmaps to implement their ID pool. This is the answer:
> > > >
> > > >   An alternative route of vendoring an existing Rust bitmap package was
> > > >   considered but suboptimal overall. Reusing the C implementation is
> > > >   preferable for a basic data structure like bitmaps. It enables Rust
> > > >   code to be a lot more similar and predictable with respect to C code
> > > >   that uses the same data structures and enables the use of code that
> > > >   has been tried-and-tested in the kernel, with the same performance
> > > >   characteristics whenever possible.
> > > >
> > > > And now it's in a commit message: 11eca92a2caeb
> > > >
> > > > They measured the affect of their wrapper on performance, and it appears
> > > > to be ~5%. See lib/find_bit_benchmark_rust.rs.
> > >
> > > You are comparing the C vs. Rust data structures here, which is not what
> > > I am proposing.
> > >
> > > Also, is this code being used on a "hot path" like the binder stuff is?
> > >
> > > > I didn't see any side-to-side comparison between any native Rust API vs
> > > > imported C bitmaps. I'm sure, I asked for that, and I still believe
> > > > it's the important piece of data to avoid this back-and-forth type of
> > > > discussions. So, Alice, Burak or anybody...
> > >
> > > Again, I'm not talking about Rust API vs. imported C bitmaps, I'm asking
> > > to use the C structures like maple-tree and idr instead of open-coding
> > > logic around the bitmap code.
> >
> > I understand your point. I asked both questions: are they sure that bitmap
> > is the most optimal data structure for the ID pool, and if so, why not use
> > the built-in Rust bitmaps? The answer was: yes, it's the most optimal, and
> > using built-in bitmaps is suboptimal overall.
>
> The Rust standard library doesn't really have a bitmap abstraction to
> begin with, so if we want to use bitmap then it's either handrolled
> bit-manipulation or the C bitmap api.
>
> cc'ing Burak's new email
>

(Thanks, I will update my email in the MAINTAINERS file.)

Binder needs to acquire bits *while holding a spinlock*. This is the
biggest constraint.

My understanding is that the IDA API call might need to allocate
memory (and sleep) when getting a new ID, as a side-effect.
So for the binder use case, it was not an option.

@Yury, about the alternative of vendoring Rust bitmap crates: that
would have duplicated the kernel's C bitmap functionality.
There does not seem much point in duplicating that, and opening the
door to have Rust and C code differently named API functions and such.
So beside performance, maintenance and coherence are also a factor.

The Rust ID pool code is merely a port of some existing
bitmap-specific binder C code (that can hopefully be deleted one day)
that deals with spinlock allocation fun. If the constraints match, I
think it is good to see it generalized and used elsewhere. That is a
conditional statement, I am not familiar with the nova use case's
performance/allocation/sleep constraints.

-- Burak