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

[Paul E. McKenney]

On Wed, Sep 09, 2026 at 07:38:20PM +0000, Josef Bacik wrote:
> On Wed, Sep 09, 2026 at 08:16:54AM -1000, Tejun Heo wrote:
> > On Wed, Sep 09, 2026 at 06:01:07PM +0000, Josef Bacik wrote:
> > > +		do {
> > > +			cond_resched_tasks_rcu_qs();
> > > +		} while (cleanup_offline_cgwb(wb));
> > 
> > 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?
> 
> Yeah I agree, it is fragile.  Every long running loop in the kernel that
> only does cond_resched() is a potential multi-minute synchronize_rcu_tasks()
> stall now that cond_resched() is a no-op on the preemption models most
> people actually run, and playing whack-a-mole with
> cond_resched_tasks_rcu_qs() at each site as we trip over them isn't a great
> long term answer.
> 
> I'm working on something more general so we don't have to sprinkle
> cond_resched_tasks_rcu_qs() everywhere, but I expect it to be controversial
> and it's going to take a while to shake out.  In the meantime these are real
> bugs that are taking machines down today, so I'd like to get the targeted
> fixes in and to stable while the broader discussion happens separately.

Looking forward to seeing what you come up with.

							Thanx, Paul