[PATCH RFC 2/6] mm/slub: add sheaf support for batching kfree_rcu() operations

[Vlastimil Babka]

On 11/14/24 17:57, Uladzislau Rezki wrote:
> On Tue, Nov 12, 2024 at 05:38:46PM +0100, Vlastimil Babka wrote:
>> --- a/kernel/rcu/tree.c
>> +++ b/kernel/rcu/tree.c
>> @@ -65,6 +65,7 @@
>>  #include <linux/kasan.h>
>>  #include <linux/context_tracking.h>
>>  #include "../time/tick-internal.h"
>> +#include "../../mm/slab.h"
>>  
>>  #include "tree.h"
>>  #include "rcu.h"
>> @@ -3420,7 +3421,7 @@ kvfree_rcu_list(struct rcu_head *head)
>>  		trace_rcu_invoke_kvfree_callback(rcu_state.name, head, offset);
>>  
>>  		if (!WARN_ON_ONCE(!__is_kvfree_rcu_offset(offset)))
>> -			kvfree(ptr);
>> +			__kvfree_rcu(ptr);
>>  
>>  		rcu_lock_release(&rcu_callback_map);
>>  		cond_resched_tasks_rcu_qs();
>> @@ -3797,6 +3798,9 @@ void kvfree_call_rcu(struct rcu_head *head, void *ptr)
>>  	if (!head)
>>  		might_sleep();
>>  
>> +	if (kfree_rcu_sheaf(ptr))
>> +		return;
>> +
>>
> This change crosses all effort which has been done in order to improve kvfree_rcu :)

Yeah I know, but it wasn't intended to make it all obsolete as I don't think
every kfree_rcu() user would have a sheaf-enabled cache.

> For example:
>   performance, app launch improvements for Android devices;
>   memory consumption optimizations to minimize LMK triggering;
>   batching to speed-up offloading;
>   etc.

Yes it's a great effort that I appreciate and you did probably all that was
possible to do without changing the slab allocator itself.

> So we have done a lot of work there. We were thinking about moving all
> functionality from "kernel/rcu" to "mm/". As a first step i can do that,
> i.e. move kvfree_rcu() as is. After that we can switch to second step.

Yeah we have discussed that with Paul at LSF/MM as well and I agreed it
makes sense, but didn't get to it yet.

> Sounds good for you or not?

Sounds good, thanks!

> --
> Uladzislau Rezki