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

[Uladzislau Rezki]

On Sun, Nov 17, 2024 at 12:01:01PM +0100, Vlastimil Babka wrote:
> 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!
> 
Thank you. Let me try to start moving it into mm/. I am thinking to place
it to the slab_common.c file. I am not sure if it makes sense to have a
dedicated file name for this purpose.

Anyway, share your view if you want to add something. Otherwise i can
proceed with that process.

--
Uladzislau Rezki