From: Ankur Arora <ankur.a.arora@oracle.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Ankur Arora <ankur.a.arora@oracle.com>,
Arnd Bergmann <arnd@arndb.de>,
linux-kernel@vger.kernel.org,
Linux-Arch <linux-arch@vger.kernel.org>,
linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org,
bpf@vger.kernel.org, Will Deacon <will@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
Mark Rutland <mark.rutland@arm.com>,
"Haris Okanovic" <harisokn@amazon.com>,
"Christoph Lameter (Ampere)" <cl@gentwo.org>,
Alexei Starovoitov <ast@kernel.org>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
"Kumar Kartikeya Dwivedi" <memxor@gmail.com>,
zhenglifeng1@huawei.com, xueshuai@linux.alibaba.com,
Joao Martins <joao.m.martins@oracle.com>,
"Boris Ostrovsky" <boris.ostrovsky@oracle.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [RESEND PATCH v7 2/7] arm64: barrier: Support smp_cond_load_relaxed_timeout()
Date: Wed, 05 Nov 2025 00:27:18 -0800 [thread overview]
Message-ID: <87jz04anq1.fsf@oracle.com> (raw)
In-Reply-To: <aQoF1-uKTgJo89W8@arm.com>
Catalin Marinas <catalin.marinas@arm.com> writes:
> On Mon, Nov 03, 2025 at 01:00:33PM -0800, Ankur Arora wrote:
>> /**
>> * smp_cond_load_relaxed_timeout() - (Spin) wait for cond with no ordering
>> * guarantees until a timeout expires.
>> * @ptr: pointer to the variable to wait on
>> * @cond: boolean expression to wait for
>> * @time_expr: time expression in caller's preferred clock
>> * @time_end: end time in nanosecond (compared against time_expr;
>> * might also be used for setting up a future event.)
>> *
>> * Equivalent to using READ_ONCE() on the condition variable.
>> *
>> * Note that the expiration of the timeout might have an architecture specific
>> * delay.
>> */
>> #ifndef smp_cond_load_relaxed_timeout
>> #define smp_cond_load_relaxed_timeout(ptr, cond_expr, time_expr, time_end_ns) \
>> ({ \
>> typeof(ptr) __PTR = (ptr); \
>> __unqual_scalar_typeof(*ptr) VAL; \
>> u32 __n = 0, __spin = SMP_TIMEOUT_POLL_COUNT; \
>> u64 __time_end_ns = (time_end_ns); \
>> \
>> for (;;) { \
>> VAL = READ_ONCE(*__PTR); \
>> if (cond_expr) \
>> break; \
>> cpu_poll_relax(__PTR, VAL, __time_end_ns); \
>
> With time_end_ns being passed to cpu_poll_relax(), we assume that this
> is always the absolute time. Do we still need time_expr in this case?
> It works for WFET as long as we can map this time_end_ns onto the
> hardware CNTVCT.
So I like this idea. Given that we only promise a coarse granularity we
should be able to get by with using a coarse clock of our choosing.
However, maybe some callers need a globally consistent clock just in
case they could migrate and do something stateful in the cond_expr?
(For instance rqspinlock wants ktime_mono. Though I don't think these
callers can migrate.)
> Alternatively, we could pass something like remaining_ns, though not
> sure how smp_cond_load_relaxed_timeout() can decide to spin before
> checking time_expr again (we probably went over this in the past two
> years ;)).
I'm sure it is in there somewhere :).
This one?: https://lore.kernel.org/lkml/aJy414YufthzC1nv@arm.com/.
Though the whole wait_policy thing confused the issue somewhat there.
Though that problem exists for both remaining_ns and for time_end_ns
with WFE. I think we are fine so long as SMP_TIMEOUT_POLL_COUNT is
defined to be 1.
For now, I think it makes sense to always pass the absolute deadline
even if the caller uses remaining_ns. So:
#define smp_cond_load_relaxed_timeout(ptr, cond_expr, time_expr, remaining_ns) \
({ \
typeof(ptr) __PTR = (ptr); \
__unqual_scalar_typeof(*ptr) VAL; \
u32 __n = 0, __spin = SMP_TIMEOUT_POLL_COUNT; \
u64 __time_start_ns = (time_expr); \
s64 __time_end_ns = __time_start_ns + (remaining_ns); \
\
for (;;) { \
VAL = READ_ONCE(*__PTR); \
if (cond_expr) \
break; \
cpu_poll_relax(__PTR, VAL, __time_end_ns); \
if (++__n < __spin) \
continue; \
if ((time_expr) >= __time_end_ns) { \
VAL = READ_ONCE(*__PTR); \
break; \
} \
__n = 0; \
} \
(typeof(*ptr))VAL; \
})
--
ankur
next prev parent reply other threads:[~2025-11-05 8:27 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-28 5:31 [RESEND PATCH v7 0/7] barrier: Add smp_cond_load_*_timeout() Ankur Arora
2025-10-28 5:31 ` [RESEND PATCH v7 1/7] asm-generic: barrier: Add smp_cond_load_relaxed_timeout() Ankur Arora
2025-10-28 9:42 ` Arnd Bergmann
2025-10-29 3:17 ` Ankur Arora
2025-11-02 21:52 ` Arnd Bergmann
2025-11-03 21:41 ` Ankur Arora
2025-10-28 16:13 ` Christoph Lameter (Ampere)
2025-10-28 5:31 ` [RESEND PATCH v7 2/7] arm64: barrier: Support smp_cond_load_relaxed_timeout() Ankur Arora
2025-10-28 8:42 ` Arnd Bergmann
2025-10-28 16:21 ` Christoph Lameter (Ampere)
2025-10-28 18:01 ` Ankur Arora
2025-10-28 21:17 ` Catalin Marinas
2025-11-02 21:39 ` Arnd Bergmann
2025-11-03 21:00 ` Ankur Arora
2025-11-04 13:55 ` Catalin Marinas
2025-11-05 8:27 ` Ankur Arora [this message]
2025-11-05 10:37 ` Arnd Bergmann
2025-11-06 0:36 ` Ankur Arora
2025-10-28 5:31 ` [RESEND PATCH v7 3/7] arm64: rqspinlock: Remove private copy of smp_cond_load_acquire_timewait() Ankur Arora
2025-10-28 5:31 ` [RESEND PATCH v7 4/7] asm-generic: barrier: Add smp_cond_load_acquire_timeout() Ankur Arora
2025-10-28 5:31 ` [RESEND PATCH v7 5/7] atomic: Add atomic_cond_read_*_timeout() Ankur Arora
2025-10-28 5:31 ` [RESEND PATCH v7 6/7] rqspinlock: Use smp_cond_load_acquire_timeout() Ankur Arora
2025-10-28 5:31 ` [RESEND PATCH v7 7/7] cpuidle/poll_state: Poll via smp_cond_load_relaxed_timeout() Ankur Arora
2025-10-28 12:30 ` Rafael J. Wysocki
2025-10-29 4:41 ` Ankur Arora
2025-10-29 18:53 ` Rafael J. Wysocki
2025-10-29 19:13 ` Ankur Arora
2025-10-29 20:29 ` Rafael J. Wysocki
2025-10-29 21:01 ` Ankur Arora
2025-11-04 18:07 ` Rafael J. Wysocki
2025-11-05 8:30 ` Ankur Arora
2025-10-28 16:16 ` Christoph Lameter (Ampere)
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=87jz04anq1.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.