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

[Paul E. McKenney]

On Wed, Sep 09, 2026 at 09:13:49AM -1000, Tejun Heo wrote:
> 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@xxxxxxxxxxxxxxxxx

Well, that was nine years ago.  ;-)

> 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().

And nine years later, I am still good with cond_resched() implying
cond_resched_tasks_rcu_qs().

The people wanting to get rid of cond_resched() might have a different
opinion, though.

							Thanx, Paul