Re: [RFC PATCH 1/7] mm/slab: introduce k[v]free_rcu() with struct rcu_ptr

[Harry Yoo <harry.yoo@oracle.com>]

On Thu, Feb 12, 2026 at 12:52:46PM +0100, Vlastimil Babka wrote:
> On 2/11/26 11:16, Uladzislau Rezki wrote:
> > On Fri, Feb 06, 2026 at 06:34:04PM +0900, Harry Yoo wrote:
> >> k[v]free_rcu() repurposes two fields of struct rcu_head: 'func' to store
> >> the start address of the object, and 'next' to link objects.
> >> 
> >> However, using 'func' to store the start address is unnecessary:
> >> 
> >>   1. slab can get the start address from the address of struct rcu_head
> >>      field via nearest_obj(), and
> >> 
> >>   2. vmalloc and large kmalloc can get the start address by aligning
> >>      down the address of the struct rcu_head field to the page boundary.
> >> 
> >> Therefore, allow an 8-byte (on 64-bit) field (of a new type called
> >> struct rcu_ptr) to be used with k[v]free_rcu() with two arguments.
> >> 
> >> Some users use both call_rcu() and k[v]free_rcu() to process callbacks
> >> (e.g., maple tree), so it makes sense to have struct rcu_head field
> >> to handle both cases. However, many users that simply free objects via
> >> kvfree_rcu() can save one pointer by using struct rcu_ptr instead of
> >> struct rcu_head.
> >> 
> >> Note that struct rcu_ptr is a single pointer only when
> >> CONFIG_KVFREE_RCU_BATCHED=y. To keep kvfree_rcu() implementation minimal
> >> when CONFIG_KVFREE_RCU_BATCHED is disabled, struct rcu_ptr is the size
> >> as struct rcu_head, and the implementation of kvfree_rcu() remains
> >> unchanged in that configuration.
> 
> Won't that be too limiting, if we can't shrink structures (e.g. BPF)
> unconditionally? Or acceptable because CONFIG_KVFREE_RCU_BATCHED=n is uncommon?

I thought BPF would be the primary user of this feature, and I believe
anyone that cares about BPF performance / memory usage will use
CONFIG_KVFREE_RCU_BATCHED=y.

But yeah, if we have more users of this feature beyond BPF, it makes sense
to reduce memory usage for CONFIG_KVFREE_RCU_BATCHED=n users with some
complexity.

-- 
Cheers,
Harry / Hyeonggon