Re: [PATCH v3 3/7] KVM: pfncache: Use RCU for readers instead of a rwlock

On Sun, Aug 09, 2026 at 06:44:55PM +0100, David Woodhouse wrote:
> On 9 August 2026 16:24:14 BST, Uladzislau Rezki <[email protected]> wrote:
> >On Sun, Aug 09, 2026 at 10:59:59AM +0100, David Woodhouse wrote:
> >> +	/*
> >> +	 * Try a non-blocking allocation first, leaving the spare untouched
> >> +	 * in the common no-pressure case so that it is still there when
> >> +	 * there really is pressure.
> >> +	 */
> >> +	node = kzalloc_objs(*node, rcu_num_nodes, GFP_NOWAIT | __GFP_NOWARN);
> >>
> >GFP_NOWAIT already contains __GFP_NOWARN. It is odd.
> 
> Ack, thanks. Will fix in my tree.
> 
> >> +	if (node)
> >> +		return node;
> >> +
> >> +	node = xchg(&srcu_spare_nodes, NULL);
> >> +	if (node) {
> >> +		schedule_work(&srcu_spare_replenish_work);
> >>
> >I am not sure but if there is a need in doing progress forward, probably
> >separate wq with WQ_MEM_RECLAIM | WQ_UNBOUND flags is better. It has an
> >extra rescue kthread to do the progress if no memory or high mem-pressure.
> 
> I don't think there is a *need* per se,  as all that happens is a few more less efficient grace periods before the allocation finally succeeds. And frankly, if memory pressure is that bad the efficiency of the grace periods is probably the least of your worries.

Probably. I was thinking about something like(example taken from driver.c):

<snip>
synchronize_srcu(&encl->srcu);
mmu_notifier_unregister(&encl_mm->mmu_notifier, encl_mm->mm);
kfree(encl_mm);
<snip>

i.e. when we need to free memory. We want a faster reclaim especially
when low memory conditions. From the other hand it looks like we do not
call quite often init_srcu_struct_nodes() from srcu_gp_end(), so no
strong opinion here.

--
Uladzislau Rezki