Re: [PATCH v8 04/12] arm64: support WFET in smp_cond_relaxed_timeout()

[Ankur Arora <ankur.a.arora@oracle.com>]

Will Deacon <will@kernel.org> writes:

> On Sun, Dec 14, 2025 at 08:49:11PM -0800, Ankur Arora wrote:
>> Extend __cmpwait_relaxed() to __cmpwait_relaxed_timeout() which takes
>> an additional timeout value in ns.
>>
>> Lacking WFET, or with zero or negative value of timeout we fallback
>> to WFE.
>>
>> Cc: Arnd Bergmann <arnd@arndb.de>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Cc: linux-arm-kernel@lists.infradead.org
>> Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
>> ---
>>  arch/arm64/include/asm/barrier.h |  8 ++--
>>  arch/arm64/include/asm/cmpxchg.h | 72 ++++++++++++++++++++++----------
>>  2 files changed, 55 insertions(+), 25 deletions(-)
>
> Sorry, just spotted something else on this...
>
>> diff --git a/arch/arm64/include/asm/barrier.h b/arch/arm64/include/asm/barrier.h
>> index 6190e178db51..fbd71cd4ef4e 100644
>> --- a/arch/arm64/include/asm/barrier.h
>> +++ b/arch/arm64/include/asm/barrier.h
>> @@ -224,8 +224,8 @@ do {									\
>>  extern bool arch_timer_evtstrm_available(void);
>>
>>  /*
>> - * In the common case, cpu_poll_relax() sits waiting in __cmpwait_relaxed()
>> - * for the ptr value to change.
>> + * In the common case, cpu_poll_relax() sits waiting in __cmpwait_relaxed()/
>> + * __cmpwait_relaxed_timeout() for the ptr value to change.
>>   *
>>   * Since this period is reasonably long, choose SMP_TIMEOUT_POLL_COUNT
>>   * to be 1, so smp_cond_load_{relaxed,acquire}_timeout() does a
>> @@ -234,7 +234,9 @@ extern bool arch_timer_evtstrm_available(void);
>>  #define SMP_TIMEOUT_POLL_COUNT	1
>>
>>  #define cpu_poll_relax(ptr, val, timeout_ns) do {			\
>> -	if (arch_timer_evtstrm_available())				\
>> +	if (alternative_has_cap_unlikely(ARM64_HAS_WFXT))		\
>> +		__cmpwait_relaxed_timeout(ptr, val, timeout_ns);	\
>> +	else if (arch_timer_evtstrm_available())			\
>>  		__cmpwait_relaxed(ptr, val);				\
>
> Don't you want to make sure that we have the event stream available for
> __cmpwait_relaxed_timeout() too? Otherwise, a large timeout is going to
> cause problems.

Would that help though? If called from smp_cond_load_relaxed_timeout()
then we would wake up and just call __cmpwait_relaxed_timeout() again.

Or did you mean other future users of __cmpwait_relaxed_timeout()?

Also I remember the event stream coming up earlier and there the intent
was to disable it if WFET was available: https://lore.kernel.org/lkml/aJ3d2uoKtDop_gQO@arm.com/.

--
ankur