[PATCH v15 12/16] cpuidle/poll_state: Wait for need-resched via tif_need_resched_relaxed_wait()

[Peter Zijlstra]

On Wed, Oct 14, 2026 at 04:23:20PM +0100, Catalin Marinas wrote:
> On Wed, Oct 14, 2026 at 03:03:06PM +0200, Peter Zijlstra wrote:
> > On Wed, Oct 14, 2026 at 10:00:18AM +0100, Catalin Marinas wrote:
> > > It
> > > would also be nice to get some acks from the atomic infrastructure
> > > maintainers.
> > 
> > That'd be Mark and me I suppose. I don't see anything substantial
> > happening, just plumbing the new function.
> 
> Thanks!
> 
> > Now, I really rather dislike timeout based schemes, but given we have
> > users, I suppose this does improve things. We should however be weary of
> > new ones I suppose.
> 
> There's some arm64 precedent in commit ebababcd0372 ("rqspinlock:
> Hardcode cond_acquire loops for arm64"). This one went in without any of
> the arm64 maintainers' ack and we've since been trying to come up with a
> generic interface instead of reverting it. It was fixing a bug where
> arm64 smp_cond_load_acquire() does not evaluate cond_expr unless the
> pointer is also written by another CPU. Arguably the bug was in the
> rqspinlock code for not using a plain cpu_relax() loop.
> 
> Anyway, we had several incarnations of this series, some with a default
> timeout but others objected to it (Arnd and Rafael IIRC), hence the
> proposal here that pleased most people (not all though ;)).

Yeah, I didn't mean to say I'm against this series -- just weary of
timeout based schemes in general.

So feel tree to pick up this series when it seems ready.