Re: [PATCH] mm/vmscan: report RCU-tasks quiescent states in shrink_lruvec()

From: Paul E. McKenney

Date: Tue Aug 11 2026 - 14:55:00 EST


On Tue, Aug 11, 2026 at 10:54:23AM -0700, Shakeel Butt wrote:
> On Tue, Aug 11, 2026 at 10:38:40AM -0700, Paul E. McKenney wrote:
> > On Mon, Aug 10, 2026 at 09:43:03PM -0700, Shakeel Butt wrote:
> > > On Mon, Aug 10, 2026 at 02:57:36AM -0700, Breno Leitao wrote:
> > > > I am seeing some rcu_tasks stalls in the Meta fleet during reclaim.
> > > >
> > > > INFO: rcu_tasks detected stalls on tasks:
> > > > 0000000088620d09: .. nvcsw: 6735/6735 holdout: 1 idle_cpu: -1/8
> > > > task:GlobalCPUThread state:R running task pid:2552016 tgid:2524552
> > > > Call Trace:
> > > > shrink_lruvec
> > > > mem_cgroup_iter
> > > > shrink_node
> > > > do_try_to_free_pages
> > > > try_to_free_pages
> > > > __alloc_frozen_pages_noprof
> > > > alloc_pages_noprof
> > > > pte_alloc_one
> > > > __pte_alloc
> > > > handle_mm_fault
> > > >
> > > > Nothing promises direct reclaim returns in bounded time, and the scan
> > > > loop in shrink_lruvec() only calls cond_resched(), which is a no-op on
> > > > PREEMPTION kernels. Involuntary preemption is not a Tasks-RCU
> > > > quiescent state, so the reclaiming task never reports one and becomes a
> > > > holdout.
> > >
> > > I still don't understand why cond_resched() is being treated as involuntary
> > > preemption but that is orthogonal to this patch.
> >
> > The history is that cond_resched() was originally intended to be a
> > preemption point in any otherwise non-preemptible kernel. Therefore,
> > because it is a preemption point, it counts as an involuntary context
> > switch.
>
> Thanks for the explanation. Is cond_resched_tasks_rcu_qs() voluntary or
> involuntary context switch?

That one is voluntary in order to take care of Tasks RCU's need for a
voluntary context switch.

Except that it doesn't bother involving the scheduler at all, but
instead just updates the current task's state with respect to Tasks RCU.
Much faster that way. ;-)

Thanx, Paul