Re: [PATCH v2 0/3] fs,mm: add kmem_cache_create_rcu()

[Vlastimil Babka <vbabka@suse.cz>]

On 8/27/24 18:05, Christian Brauner wrote:
> On Tue, Aug 27, 2024 at 05:59:41PM GMT, Christian Brauner wrote:
>> When a kmem cache is created with SLAB_TYPESAFE_BY_RCU the free pointer
>> must be located outside of the object because we don't know what part of
>> the memory can safely be overwritten as it may be needed to prevent
>> object recycling.
>> 
>> That has the consequence that SLAB_TYPESAFE_BY_RCU may end up adding a
>> new cacheline. This is the case for .e.g, struct file. After having it
>> shrunk down by 40 bytes and having it fit in three cachelines we still
>> have SLAB_TYPESAFE_BY_RCU adding a fourth cacheline because it needs to
>> accomodate the free pointer and is hardware cacheline aligned.
>> 
>> I tried to find ways to rectify this as struct file is pretty much
>> everywhere and having it use less memory is a good thing. So here's a
>> proposal.
>> 
>> I was hoping to get something to this effect into v6.12.
>> 
>> If we really want to switch to a struct to pass kmem_cache parameters I
>> can do the preparatory patch to convert all kmem_cache_create() and
>> kmem_cache_create_usercopy() callers to use a struct for initialization
>> of course. I can do this as a preparatory work or as follow-up work to
>> this series. Thoughts?
> 
> So one thing I can do is to add:
> 
> struct kmem_cache_args {
> 	.freeptr_offset,
> 	.useroffset,
> 	.flags,
> 	.name,
> };

Hm basically everyone uses name, size and some flags, so how about we leave
those as direct parameters and args is for the rest, and in most cases would
be NULL.

> accompanied by:
> 
> int kmem_create_cache(struct kmem_cache_args *args);

I think we can't reuse the name with different parameters as long the old
one exists?

> and then switch both the filp cache and Jens' io_kiocb cache over to use
> these two helpers. Then we can convert other callers one by one.
> 
> @Vlastimil, @Jens, @Linus what do you think?

In the other thread you said it's best to leave such refactoring to
maintainers and I agree and don't ask you to do the cleanup in order to get
what you need (and we don't need to rush it either).