Linux Power Management development
 help / color / mirror / Atom feed
From: bot+bpf-ci@kernel.org
To: 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
Cc: arnd@arndb.de,catalin.marinas@arm.com,will@kernel.org,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,rdunlap@infradead.org,david.laight.linux@gmail.com,broonie@kernel.org,joao.m.martins@oracle.com,boris.ostrovsky@oracle.com,konrad.wilk@oracle.com,ashok.bhat@arm.com,ankur.a.arora@oracle.com,ast@kernel.org,andrii@kernel.org,daniel@iogearbox.net,martin.lau@kernel.org,eddyz87@gmail.com,yonghong.song@linux.dev,mason@kernel.org,ihor.solodrai@linux.dev
Subject: Re: [PATCH v15 04/16] arm64: support WFET in smp_cond_load_relaxed_timeout()
Date: Mon, 31 Aug 2026 21:16:58 +0000 (UTC)	[thread overview]
Message-ID: <f47a36669d06226dec908ca89ff9d04bdfd594844394b09ef45c4291283532ea@mail.kernel.org> (raw)
In-Reply-To: <20260831202251.305046-5-ankur.a.arora@oracle.com>

[-- Attachment #1: Type: text/plain, Size: 2458 bytes --]

> arm64: support WFET in smp_cond_load_relaxed_timeout()
>
> To handle WFET use __cmpwait_timeout() similarly to __cmpwait(). These
> call out to the respective __cmpwait_case_timeout_##sz(),
> __cmpwait_case_##sz() functions.

This isn't a bug, but could the changelog say why the WFET path is
preferred over the event-stream path, and note how the deadline is
derived (and on which counter base), rather than describing which macros
call which?

> diff --git a/arch/arm64/include/asm/barrier.h b/arch/arm64/include/asm/barrier.h
> index d186a4558776..d1f4f571adaa 100644
> --- a/arch/arm64/include/asm/barrier.h
> +++ b/arch/arm64/include/asm/barrier.h

[ ... ]

> diff --git a/arch/arm64/include/asm/cmpxchg.h b/arch/arm64/include/asm/cmpxchg.h
> index 6cf3cd6873f5..7985ae5ceb0f 100644
> --- a/arch/arm64/include/asm/cmpxchg.h
> +++ b/arch/arm64/include/asm/cmpxchg.h

[ ... ]

> @@ -235,20 +237,52 @@ __CMPWAIT_CASE( ,  , 64);
>
>  #undef __CMPWAIT_CASE
>
> +#define __CMPWAIT_TIMEOUT_CASE(w, sfx, sz)				\
> +static inline void __cmpwait_case_timeout_##sz(volatile void *ptr,	\
> +					       unsigned long val,	\
> +					       u64 timeout_ns)		\
> +{									\
> +	unsigned long tmp;						\
> +	u64 ecycles = __delay_cycles() +				\
> +			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));			\
> +}

This isn't a bug, but since only the final wait instruction differs
from __CMPWAIT_CASE (the sevl/wfe/ldxr/eor/cbnz prologue and the
operand lists are identical), would folding the two into one macro that
takes the wait instruction (and the optional deadline operand) read
better, in the style of __XCHG_CASE()? And is the 1f -> 2f label
renumbering needed?

> +
> +__CMPWAIT_TIMEOUT_CASE(w, b, 8);
> +__CMPWAIT_TIMEOUT_CASE(w, h, 16);
> +__CMPWAIT_TIMEOUT_CASE(w,  , 32);
> +__CMPWAIT_TIMEOUT_CASE( ,  , 64);
> +
> +#undef __CMPWAIT_TIMEOUT_CASE

[ ... ]


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/33438155296

  reply	other threads:[~2026-08-31 21:17 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-31 20:22 [PATCH v15 00/16] barrier: Add smp_cond_load_{relaxed,acquire}_timeout() Ankur Arora
2026-08-31 20:22 ` [PATCH v15 01/16] asm-generic: barrier: Add smp_cond_load_relaxed_timeout() Ankur Arora
2026-08-31 20:22 ` [PATCH v15 02/16] arm64: barrier: Support smp_cond_load_relaxed_timeout() Ankur Arora
2026-08-31 20:22 ` [PATCH v15 03/16] arm64/delay: move, fixup usecs_to_cycles() Ankur Arora
2026-08-31 20:22 ` [PATCH v15 04/16] arm64: support WFET in smp_cond_load_relaxed_timeout() Ankur Arora
2026-08-31 21:16   ` bot+bpf-ci [this message]
2026-08-31 20:22 ` [PATCH v15 05/16] arm64: rqspinlock: Remove private copy of smp_cond_load_acquire_timewait() Ankur Arora
2026-08-31 20:22 ` [PATCH v15 06/16] asm-generic: barrier: Add smp_cond_load_acquire_timeout() Ankur Arora
2026-08-31 21:17   ` bot+bpf-ci
2026-08-31 20:22 ` [PATCH v15 07/16] atomic: Add atomic_cond_read_*_timeout() Ankur Arora
2026-08-31 21:16   ` bot+bpf-ci
2026-08-31 20:22 ` [PATCH v15 08/16] locking/atomic: scripts: build atomic_long_cond_read_*_timeout() Ankur Arora
2026-08-31 20:22 ` [PATCH v15 09/16] bpf/rqspinlock: switch check_timeout() to a clock interface Ankur Arora
2026-08-31 21:16   ` bot+bpf-ci
2026-08-31 20:22 ` [PATCH v15 10/16] bpf/rqspinlock: Use smp_cond_load_acquire_timeout() Ankur Arora
2026-08-31 21:31   ` bot+bpf-ci
2026-08-31 20:22 ` [PATCH v15 11/16] sched: add need-resched timed wait interface Ankur Arora
2026-08-31 20:22 ` [PATCH v15 12/16] cpuidle/poll_state: Wait for need-resched via tif_need_resched_relaxed_wait() Ankur Arora
2026-08-31 20:22 ` [PATCH v15 13/16] arm64/delay: enable testing smp_cond_load_relaxed_timeout() Ankur Arora
2026-08-31 21:16   ` bot+bpf-ci
2026-08-31 20:22 ` [PATCH v15 14/16] barrier: add tests for smp_cond_load_*_timeout() Ankur Arora
2026-08-31 21:17   ` bot+bpf-ci
2026-08-31 20:22 ` [PATCH v15 15/16] barrier: timeout validity checks for smp_cond_load_relaxed_timeout() Ankur Arora
2026-08-31 21:16   ` bot+bpf-ci
2026-08-31 20:22 ` [PATCH v15 16/16] barrier: timeout validity checks for smp_cond_load_acquire_timeout() Ankur Arora

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=f47a36669d06226dec908ca89ff9d04bdfd594844394b09ef45c4291283532ea@mail.kernel.org \
    --to=bot+bpf-ci@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=andrii@kernel.org \
    --cc=ankur.a.arora@oracle.com \
    --cc=arnd@arndb.de \
    --cc=ashok.bhat@arm.com \
    --cc=ast@kernel.org \
    --cc=boris.ostrovsky@oracle.com \
    --cc=bpf@vger.kernel.org \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=cl@gentwo.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=daniel@iogearbox.net \
    --cc=david.laight.linux@gmail.com \
    --cc=eddyz87@gmail.com \
    --cc=harisokn@amazon.com \
    --cc=ihor.solodrai@linux.dev \
    --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=martin.lau@kernel.org \
    --cc=mason@kernel.org \
    --cc=memxor@gmail.com \
    --cc=peterz@infradead.org \
    --cc=rafael@kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=will@kernel.org \
    --cc=xueshuai@linux.alibaba.com \
    --cc=yonghong.song@linux.dev \
    --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