Message-Id: <746c2de4-7613-4f13-911c-c2c4e071ed73@app.fastmail.com>
Date: Sun, 02 Nov 2025 22:39:42 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Catalin Marinas" <catalin.marinas@....com>,
 "Ankur Arora" <ankur.a.arora@...cle.com>
Cc: linux-kernel@...r.kernel.org, Linux-Arch <linux-arch@...r.kernel.org>,
 linux-arm-kernel@...ts.infradead.org, linux-pm@...r.kernel.org,
 bpf@...r.kernel.org, "Will Deacon" <will@...nel.org>,
 "Peter Zijlstra" <peterz@...radead.org>,
 "Andrew Morton" <akpm@...ux-foundation.org>,
 "Mark Rutland" <mark.rutland@....com>,
 "Haris Okanovic" <harisokn@...zon.com>,
 "Christoph Lameter (Ampere)" <cl@...two.org>,
 "Alexei Starovoitov" <ast@...nel.org>,
 "Rafael J . Wysocki" <rafael@...nel.org>,
 "Daniel Lezcano" <daniel.lezcano@...aro.org>,
 "Kumar Kartikeya Dwivedi" <memxor@...il.com>, zhenglifeng1@...wei.com,
 xueshuai@...ux.alibaba.com, "Joao Martins" <joao.m.martins@...cle.com>,
 "Boris Ostrovsky" <boris.ostrovsky@...cle.com>,
 "Konrad Rzeszutek Wilk" <konrad.wilk@...cle.com>
Subject: Re: [RESEND PATCH v7 2/7] arm64: barrier: Support
 smp_cond_load_relaxed_timeout()

On Tue, Oct 28, 2025, at 22:17, Catalin Marinas wrote:
> On Tue, Oct 28, 2025 at 11:01:22AM -0700, Ankur Arora wrote:
>> Arnd Bergmann <arnd@...db.de> writes:
>> > On Tue, Oct 28, 2025, at 06:31, Ankur Arora wrote:
>> >> +
>> >
>> > Since the caller knows exactly how long it wants to wait for,
>> > we should be able to fit a 'wfet' based primitive in here and
>> > pass the timeout as another argument.
>> 
>> Per se, I don't disagree with this when it comes to WFET.
>> 
>> Handling a timeout, however, is messier when we use other mechanisms.
>> 
>> Some problems that came up in my earlier discussions with Catalin:
>> 
>>   - when using WFE, we also need some notion of slack
>>     - and if a caller specifies only a small or no slack, then we need
>>       to combine WFE+cpu_relax()

I don't see the difference to what you have: with the event stream,
you implicitly define a slack to be the programmed event stream rate
of ~100µs.


I'm not asking for anything better in this case, only for machines
with WFET but no event stream to also avoid the spin loop.

>>   - for platforms that only use a polling primitive, we want to check
>>     the clock only intermittently for power reasons.

Right, I missed that bit.

>>     Now, this could be done with an architecture specific spin-count.
>>     However, if the caller specifies a small slack, then we might need
>>     to we check the clock more often as we get closer to the deadline etc.

Again, I think this is solved by defining the slack as architecture
specific as well rather than an explicit argument, which is essentially
what we already have.
 
>> A smaller problem was that different users want different clocks and so
>> folding the timeout in a 'timeout_cond_expr' lets us do away with the
>> interface having to handle any of that.
>>
>> I had earlier versions [v2] [v3] which had rather elaborate policies for
>> handling timeout, slack etc. But, given that the current users of the
>> interface don't actually care about precision, all of that seemed
>> a little overengineered.
>
> Indeed, we've been through all these options and without a concrete user
> that needs a more precise timeout, we decided it's not worth it. It can,
> however, be improved later if such users appear.

The main worry I have is that we get too many users of cpu_poll_relax()
hardcoding the use of the event stream without a timeout argument, it
becomes too hard to change later without introducing regressions
from the behavior change.

As far as I can tell, the only place that currently uses the
event stream on a functional level is the delay() loop, and that
has a working wfet based version.

     Arnd

Powered by blists - more mailing lists