On Fri, Jun 28, 2024 at 10:40 AM Vlastimil Babka [off-list ref] wrote:

On 6/28/24 7:35 AM, Boqun Feng wrote:

quoted

On Thu, Jun 20, 2024 at 10:43:39PM +0200, Vlastimil Babka wrote:

quoted

On 6/20/24 8:54 PM, Kees Cook wrote:

quoted

On Thu, Jun 20, 2024 at 03:56:27PM +0200, Vlastimil Babka wrote:

quoted

quoted

@@ -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.

quoted

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.

quoted

quoted

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