[PATCH v15 12/16] cpuidle/poll_state: Wait for need-resched via tif_need_resched_relaxed_wait()
Ankur Arora
ankur.a.arora at oracle.com
Thu Oct 15 00:06:48 PDT 2026
Catalin Marinas <catalin.marinas at arm.com> writes:
> This Message Is From an External Sender
> This message came from outside your organization.
> Report Suspicious
>
> 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 ;)).
:).
I have a new version that I should be sending out shortly that fixes
the few bot comments.
Plus there was a edge case around the control dependency in the
acquire variant that should also be hopefully resolved.
--
ankur
More information about the linux-arm-kernel
mailing list