Re: [PATCH] rust: slab: add basic slab module

Elijah
2025-09-25T17:20:41Z

I was thinking of maybe creating something like KBox for kmem_cache but
I didn't want to touch allocator code yet, I figured I would just create
the groundwork for that to exist. rbtree.rs uses KBox now but I'm not
sure it should, at least if it's going to scale to many nodes

On 9/25/2025 2:54 AM, Danilo Krummrich wrote:
> What's the motivation?
>
> I mean, we will need kmem_cache soon. But the users will all be drivers, e.g.
> the GPU drivers that people work on currently.
>
> Drivers shouldn't use "raw" allocators (such as Kmalloc [1] or Vmalloc [2]), but
> the corresponding "managed" allocation primitives, such as KBox [3], VBox [4],
> KVec, etc.
>
> Therefore, the code below shouldn't be used by drivers directly, hence the
> question for motivation.
>
> In any case, kmem_cache is a special allocator (special as in it can have a
> non-static lifetime in contrast to other kernel allocators) and should be
> integrated with the existing infrastructure in rust/kernel/alloc/.
>
> I think there are multiple options for that; (1) isn't really an option, but I
> think it's good to mention anyways:
>
> (1) Allow for non-zero sized implementations of the Allocator trait [3], such
> that we can store a reference count to the KmemCache. This is necessary to
> ensure that a Box<T, KmemCache> can't out-live the KmemCache itself.
>
> The reason why I said it's not really an option is because it discards the
> option for dynamic dispatch of the generic Box type.
>
> (2) Same as (1), but with a custom Box type. This keeps dynamic dispatch for
> the generic Box type (i.e. KBox, VBox, KVBox), but duplicates quite some
> code and still doesn't allow for dynamic dispatch for the KmemCacheBox.
>
> (3) Implement a macro to generate a custom KmemCache Allocator trait
> implementation for every KmemCache instance with a static lifetime.
>
> This makes KmemCache technically equivalent to the other allocators, such
> as Kmalloc, etc. but obviously has the downside that the KmemCache might
> live much longer than required.
>
> Technically, most KmemCache instances live for the whole module lifetime,
> so it might be fine though.
>
> (This is what I think Alice proposed.)
>
> (4) Solve the problem on the C side and let kmem_cache_alloc() take care of
> acquiring a reference count to the backing kmem_cache. The main question
> here would be where to store the pointer for decreasing the reference
> count on kmem_cache_free().
>
> Theoretically, it could be stored within the allocation itself, but it's a
> bit of a yikes.
>
> However, it would resolve all the mentioned problems above.
>
> I'd like to see (3) or (4), also depending on what the MM folks think.