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
