linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ankur Arora <ankur.a.arora@oracle.com>
To: Will Deacon <will@kernel.org>
Cc: Ankur Arora <ankur.a.arora@oracle.com>,
	linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org,
	bpf@vger.kernel.org, arnd@arndb.de, catalin.marinas@arm.com,
	peterz@infradead.org, akpm@linux-foundation.org,
	mark.rutland@arm.com, harisokn@amazon.com, cl@gentwo.org,
	ast@kernel.org, rafael@kernel.org, daniel.lezcano@linaro.org,
	memxor@gmail.com, zhenglifeng1@huawei.com,
	xueshuai@linux.alibaba.com, joao.m.martins@oracle.com,
	boris.ostrovsky@oracle.com, konrad.wilk@oracle.com
Subject: Re: [PATCH v8 04/12] arm64: support WFET in smp_cond_relaxed_timeout()
Date: Fri, 09 Jan 2026 10:55:18 -0800	[thread overview]
Message-ID: <87y0m6mx9l.fsf@oracle.com> (raw)
In-Reply-To: <aWENsQywXuM880_l@willie-the-truck>


Will Deacon <will@kernel.org> writes:

> On Fri, Jan 09, 2026 at 01:05:57AM -0800, Ankur Arora wrote:
>>
>> Will Deacon <will@kernel.org> writes:
>>
>> > On Sun, Dec 14, 2025 at 08:49:11PM -0800, Ankur Arora wrote:
>> >> +#define __CMPWAIT_CASE(w, sfx, sz)						\
>> >> +static inline void __cmpwait_case_##sz(volatile void *ptr,			\
>> >> +				       unsigned long val,			\
>> >> +				       s64 timeout_ns)				\
>> >> +{										\
>> >> +	unsigned long tmp;							\
>> >> +										\
>> >> +	if (!alternative_has_cap_unlikely(ARM64_HAS_WFXT) || timeout_ns <= 0) {	\
>> >> +		asm volatile(							\
>> >> +		"	sevl\n"							\
>> >> +		"	wfe\n"							\
>> >> +		"	ldxr" #sfx "\t%" #w "[tmp], %[v]\n"			\
>> >> +		"	eor	%" #w "[tmp], %" #w "[tmp], %" #w "[val]\n"	\
>> >> +		"	cbnz	%" #w "[tmp], 1f\n"				\
>> >> +		"	wfe\n"							\
>> >> +		"1:"								\
>> >> +		: [tmp] "=&r" (tmp), [v] "+Q" (*(u##sz *)ptr)			\
>> >> +		: [val] "r" (val));						\
>> >> +	} else {								\
>> >> +		u64 ecycles = arch_timer_read_counter() +			\
>> >> +				NSECS_TO_CYCLES(timeout_ns);			\
>> >> +		asm volatile(							\
>> >> +		"	sevl\n"							\
>> >> +		"	wfe\n"							\
>> >> +		"	ldxr" #sfx "\t%" #w "[tmp], %[v]\n"			\
>> >> +		"	eor	%" #w "[tmp], %" #w "[tmp], %" #w "[val]\n"	\
>> >> +		"	cbnz	%" #w "[tmp], 2f\n"				\
>> >> +		"	msr s0_3_c1_c0_0, %[ecycles]\n"				\
>> >> +		"2:"								\
>> >> +		: [tmp] "=&r" (tmp), [v] "+Q" (*(u##sz *)ptr)			\
>> >> +		: [val] "r" (val), [ecycles] "r" (ecycles));			\
>> >> +	}									\
>> >
>> > Why not have a separate helper for the WFXT version and avoid the runtime
>> > check on timeout_ns?
>>
>> My main reason for keeping them together was that a separate helper
>> needed duplication of a lot of the __CMPWAIT_CASE and __CMPWAIT_GEN
>> stuff.
>>
>> Relooking at it, I think we could get by without duplicating the
>> __CMPWAIT_GEN (the WFE helper just needs to take an unused timeout_ns
>> paramter).
>>
>> But, it seems overkill to get rid of the unnecessary check on timeout_ns
>> (which AFAICT should be well predicted) and the duplicate static branch.
>
> tbh, I was actually struggling to see what the check achieves. In fact,
> why is 'timeout_ns' signed in the first place? Has BPF invented time
> travel now? :p

Worse. I had to invent it for them :D.

The BPF rqspinlock needs to be able to return failure (-EDEADLOCK, -ETIMEDOUT).
What seemed to me to be the most natural way was for the clock used by
rqspinlock itself returning either the clock value or an error value.

So that necessitated the top level timeout_ns to be signed.

Now the error would get filtered out by smp_cond_load_relaxed_timeout()
so cpu_poll_relax() should be called with a positive value of timeout_ns.

> If the requested timeout is 0 then we should return immediately (or issue
> a WFET which will wake up immediately).
>
> If the requested timeout is negative, then WFET may end up with a really
> long timeout, but that should still be no worse than a plain WFE.

cpu_poll_relax() should not be called with 0 or a negative value.
I'll add a comment to that effect.

> If the check is only there to de-multiplex __cmpwait() vs
> __cmpwait_relaxed_timeout() as the caller, then I think we should just
> avoid muxing them in the first place.

Yes that's a good point. That the only reason that check exists. And we can
do without it since cpu_poll_relax() has all the information it needs to
do the de-multiplexing.

> The duplication argument doesn't
> hold a lot of water when the asm block is already mostly copy-paste.

Fair enough.

--
ankur

  reply	other threads:[~2026-01-09 18:57 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-15  4:49 [PATCH v8 00/12] barrier: Add smp_cond_load_{relaxed,acquire}_timeout() Ankur Arora
2025-12-15  4:49 ` [PATCH v8 01/12] asm-generic: barrier: Add smp_cond_load_relaxed_timeout() Ankur Arora
2025-12-22  7:47   ` Ankur Arora
2025-12-15  4:49 ` [PATCH v8 02/12] arm64: barrier: Support smp_cond_load_relaxed_timeout() Ankur Arora
2026-01-08 21:36   ` Will Deacon
2026-01-09  9:06     ` Ankur Arora
2025-12-15  4:49 ` [PATCH v8 03/12] arm64/delay: move some constants out to a separate header Ankur Arora
2025-12-15 17:59   ` kernel test robot
2025-12-19  4:52   ` kernel test robot
2025-12-15  4:49 ` [PATCH v8 04/12] arm64: support WFET in smp_cond_relaxed_timeout() Ankur Arora
2026-01-08 21:35   ` Will Deacon
2026-01-09  9:05     ` Ankur Arora
2026-01-09 14:16       ` Will Deacon
2026-01-09 18:55         ` Ankur Arora [this message]
2026-01-09 14:17   ` Will Deacon
2026-01-09 19:05     ` Ankur Arora
2025-12-15  4:49 ` [PATCH v8 05/12] arm64: rqspinlock: Remove private copy of smp_cond_load_acquire_timewait() Ankur Arora
2025-12-15  5:14   ` bot+bpf-ci
2025-12-15  4:49 ` [PATCH v8 06/12] asm-generic: barrier: Add smp_cond_load_acquire_timeout() Ankur Arora
2025-12-15  4:49 ` [PATCH v8 07/12] atomic: Add atomic_cond_read_*_timeout() Ankur Arora
2026-01-09 14:11   ` Will Deacon
2026-01-09 19:06     ` Ankur Arora
2025-12-15  4:49 ` [PATCH v8 08/12] locking/atomic: scripts: build atomic_long_cond_read_*_timeout() Ankur Arora
2025-12-15  4:49 ` [PATCH v8 09/12] bpf/rqspinlock: switch check_timeout() to a clock interface Ankur Arora
2025-12-15  4:49 ` [PATCH v8 10/12] bpf/rqspinlock: Use smp_cond_load_acquire_timeout() Ankur Arora
2025-12-15 21:40   ` Alexei Starovoitov
2025-12-16  7:34     ` Ankur Arora
2025-12-15  4:49 ` [PATCH v8 11/12] sched: add need-resched timed wait interface Ankur Arora
2025-12-15  4:49 ` [PATCH v8 12/12] cpuidle/poll_state: Wait for need-resched via tif_need_resched_relaxed_wait() Ankur Arora
2025-12-15 11:11   ` Rafael J. Wysocki
2025-12-16  6:55     ` Ankur Arora
2025-12-15 21:23   ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y0m6mx9l.fsf@oracle.com \
    --to=ankur.a.arora@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=ast@kernel.org \
    --cc=boris.ostrovsky@oracle.com \
    --cc=bpf@vger.kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=cl@gentwo.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=harisokn@amazon.com \
    --cc=joao.m.martins@oracle.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=memxor@gmail.com \
    --cc=peterz@infradead.org \
    --cc=rafael@kernel.org \
    --cc=will@kernel.org \
    --cc=xueshuai@linux.alibaba.com \
    --cc=zhenglifeng1@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).