On 7/23/25 18:39, Uladzislau Rezki wrote:
> On Wed, Jul 23, 2025 at 03:34:35PM +0200, Vlastimil Babka wrote:
>> static bool
>> need_offload_krc(struct kfree_rcu_cpu *krcp)
>> {
>> @@ -1952,6 +1973,9 @@ void kvfree_call_rcu(struct rcu_head *head, void *ptr)
>> if (!head)
>> might_sleep();
>>
>> + if (kfree_rcu_sheaf(ptr))
>> + return;
>> +
>>
> I have a question here. kfree_rcu_sheaf(ptr) tries to revert freeing
> an object over one more newly introduced path. This patch adds infra
> for such purpose whereas we already have a main path over which we
> free memory.
>
> Why do not we use existing logic? As i see you can do:
>
> if (unlikely(!slab_free_hook(s, p[i], init, true))) {
> p[i] = p[--sheaf->size];
> continue;
> }
>
> in the kfree_rcu_work() function where we process all ready to free objects.
I'm not sure I understand. In kfree_rcu_work() we process individual
objects. There is no sheaf that you reference in the code above?
Or are you suggesting we add e.g. a "channel" of sheaves to process in
addition to the existing channels of objects?
> I mean, for slab objects we can replace kfree_bulk() and scan all pointers
> and free them over slab_free_hook().
The desired outcome after __rcu_free_sheaf_prepare() is to take the whole
sheaf and have it reused, not free individual objects. So we call
slab_free_hook() in __rcu_free_sheaf_prepare() but don't actually free
individual objects as necessary.
> Also we do use a pooled API and other improvements to speed up freeing.
It could be useful to know the details as in Suren's measurements there's
issues with kfree_rcu() using sheaves when lazy rcu is used. Is the
kfree_rcu() infra avoiding being too lazy somehow? We could use the same
techniques for sheaves.
> Thanks!
>
> --
> Uladzislau Rezki
