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?
