Re: [PATCH] writeback: report a Tasks-RCU quiescent state per cgwb drain pass

[Tejun Heo <tj@kernel.org>]

Hello,

On Wed, Sep 09, 2026 at 12:03:20PM -0700, Paul E. McKenney wrote:
> > The patch looks fine but this overall seems fragile. cond_resched() was
> > already marking "stuff that can take too long" but we need to use
> > cond_resched_tasks_rcu_qs() if it can take *really* long. There gotta be a
> > way to make this more maintainable. If always doing tasks_rcu_qs from
> > cond_resched() is too expensive, can it be be gated behind something cheaper
> > e.g. some tick based test?
> 
> This is the business end of cond_resched_tasks_rcu_qs() in preemptible
> kernels (in which cond_resched() is nothingness):
> 
> # define rcu_tasks_classic_qs(t, preempt)				\
> 	do {								\
> 		if (!(preempt) && READ_ONCE((t)->rcu_tasks_holdout))	\
> 			WRITE_ONCE((t)->rcu_tasks_holdout, false);	\
> 	} while (0)
> 
> This is pretty lightweight.  Adding a jiffies check would likely make
> it more expensive.
> 
> Or am I missing your point?

I found the following thread for why there is a separate variant for
cond_resched_tasks_rcu_qs():

  https://lkml.kernel.org/r/20180224151240.0d63a059@vmware.local.home

The rationale was that it'd make cond_resched() expensive, so I assumed it
was relatively heavy. If it already comes down to a single test, I'm not
sure having a separate interface makes a lot of sense. There isn't some
semantical difference between the two, right? Anything which takes long
enough needs to do the tasks rcu qs, and that is what we mark with
cond_resched().

Thanks.

-- 
tejun