On Fri, Jun 28, 2024 at 10:40 AM Vlastimil Babka <vbabka@xxxxxxx> wrote: > > On 6/28/24 7:35 AM, Boqun Feng wrote: > > On Thu, Jun 20, 2024 at 10:43:39PM +0200, Vlastimil Babka wrote: > >> On 6/20/24 8:54 PM, Kees Cook wrote: > >> > On Thu, Jun 20, 2024 at 03:56:27PM +0200, Vlastimil Babka wrote: > >> >> > @@ -549,6 +549,11 @@ void *kmem_cache_alloc_lru_noprof(struct kmem_cache *s, struct list_lru *lru, > >> >> > > >> >> > void kmem_cache_free(struct kmem_cache *s, void *objp); > >> >> > > >> >> > +kmem_buckets *kmem_buckets_create(const char *name, unsigned int align, > >> >> > + slab_flags_t flags, > >> >> > + unsigned int useroffset, unsigned int usersize, > >> >> > + void (*ctor)(void *)); > >> >> > >> >> I'd drop the ctor, I can't imagine how it would be used with variable-sized > >> >> allocations. > >> > > >> > I've kept it because for "kmalloc wrapper" APIs, e.g. devm_kmalloc(), > >> > there is some "housekeeping" that gets done explicitly right now that I > >> > think would be better served by using a ctor in the future. These APIs > >> > are variable-sized, but have a fixed size header, so they have a > >> > "minimum size" that the ctor can still operate on, etc. > >> > > >> >> Probably also "align" doesn't make much sense since we're just > >> >> copying the kmalloc cache sizes and its implicit alignment of any > >> >> power-of-two allocations. > >> > > >> > Yeah, that's probably true. I kept it since I wanted to mirror > >> > kmem_cache_create() to make this API more familiar looking. > >> > >> Rust people were asking about kmalloc alignment (but I forgot the details) > > > > It was me! The ask is whether we can specify the alignment for the > > allocation API, for example, requesting a size=96 and align=32 memory, > > or the allocation API could do a "best alignment", for example, > > allocating a size=96 will give a align=32 memory. As far as I > > understand, kmalloc() doesn't support this. > > Hm yeah we only have guarantees for power-or-2 allocations. > > >> so maybe this could be useful for them? CC rust-for-linux. > >> > > > > I took a quick look as what kmem_buckets is, and seems to me that align > > doesn't make sense here (and probably not useful in Rust as well) > > because a kmem_buckets is a set of kmem_caches, each has its own object > > size, making them share the same alignment is probably not what you > > want. But I could be missing something. > > How flexible do you need those alignments to be? Besides the power-of-two > guarantees, we currently have only two odd sizes with 96 and 192. If those > were guaranteed to be aligned 32 bytes, would that be sufficient? Also do > you ever allocate anything smaller than 32 bytes then? > > To summarize, if Rust's requirements can be summarized by some rules and > it's not completely ad-hoc per-allocation alignment requirement (or if it > is, does it have an upper bound?) we could perhaps figure out the creation > of rust-specific kmem_buckets to give it what's needed? Rust's allocator API can take any size and alignment as long as: 1. The alignment is a power of two. 2. The size is non-zero. 3. When you round up the size to the next multiple of the alignment, then it must not overflow the signed type isize / ssize_t. What happens right now is that when Rust wants an allocation with a higher alignment than ARCH_SLAB_MINALIGN, then it will increase size until it becomes a power of two so that the power-of-two guarantee gives a properly aligned allocation. Alice
