arch/arm64/include/asm/barrier.h | 74 ++++++++++++++++++++++++++++++++ include/asm-generic/barrier.h | 71 ++++++++++++++++++++++++++++++ 2 files changed, 145 insertions(+)
Hi,
This series adds waited variants of the smp_cond_load() primitives:
smp_cond_load_relaxed_timewait(), and smp_cond_load_acquire_timewait().
There are two known users for these interfaces:
- poll_idle() [1]
- resilient queued spinlocks [2]
For both of these cases we want to wait on a condition but also want
to terminate the wait at some point.
Now, in theory, that can be worked around by making the time check a
part of the conditional expression provided to smp_cond_load_*():
smp_cond_load_relaxed(&cvar, !VAL || time_check());
That approach, however, runs into two problems:
- smp_cond_load_*() only allow waiting on a condition: this might
be okay when we are synchronously spin-waiting on the condition,
but not on architectures where are actually waiting for a store
to a cacheline.
- this semantic problem becomes a real problem on arm64 if the
event-stream is disabled. That means that there will be no
asynchronous event (the event-stream) that periodically wakes
the waiter, which might lead to an interminable wait if VAL is
never written to.
This series extends the smp_cond_load_*() interfaces by adding two
arguments: a time-check expression and its associated time limit.
This is sufficient to allow for both a synchronously waited
implementation (like the generic cpu_relax() based loop), or one
where the CPU waits for a store to a cacheline with an out-of-band
timer.
Any comments appreciated!
Ankur
[1] https://lore.kernel.org/lkml/20241107190818.522639-3-ankur.a.arora@oracle.com/
[2] https://lore.kernel.org/lkml/20250107140004.2732830-9-memxor@gmail.com/
--
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Cc: linux-arch@vger.kernel.org
Ankur Arora (4):
asm-generic: barrier: Add smp_cond_load_relaxed_timewait()
asm-generic: barrier: Add smp_cond_load_acquire_timewait()
arm64: barrier: Add smp_cond_load_relaxed_timewait()
arm64: barrier: Add smp_cond_load_acquire_timewait()
arch/arm64/include/asm/barrier.h | 74 ++++++++++++++++++++++++++++++++
include/asm-generic/barrier.h | 71 ++++++++++++++++++++++++++++++
2 files changed, 145 insertions(+)
--
2.43.5
Ankur Arora <ankur.a.arora@oracle.com> writes: > Hi, > > This series adds waited variants of the smp_cond_load() primitives: > smp_cond_load_relaxed_timewait(), and smp_cond_load_acquire_timewait(). > > There are two known users for these interfaces: > > - poll_idle() [1] The next version of the poll_idle() series (goes on top of this one): https://lore.kernel.org/lkml/20250218213337.377987-1-ankur.a.arora@oracle.com/ Ankur > - resilient queued spinlocks [2] > > For both of these cases we want to wait on a condition but also want > to terminate the wait at some point. > > Now, in theory, that can be worked around by making the time check a > part of the conditional expression provided to smp_cond_load_*(): > > smp_cond_load_relaxed(&cvar, !VAL || time_check()); > > That approach, however, runs into two problems: > > - smp_cond_load_*() only allow waiting on a condition: this might > be okay when we are synchronously spin-waiting on the condition, > but not on architectures where are actually waiting for a store > to a cacheline. > > - this semantic problem becomes a real problem on arm64 if the > event-stream is disabled. That means that there will be no > asynchronous event (the event-stream) that periodically wakes > the waiter, which might lead to an interminable wait if VAL is > never written to. > > This series extends the smp_cond_load_*() interfaces by adding two > arguments: a time-check expression and its associated time limit. > This is sufficient to allow for both a synchronously waited > implementation (like the generic cpu_relax() based loop), or one > where the CPU waits for a store to a cacheline with an out-of-band > timer. > > Any comments appreciated! > > > Ankur > > [1] https://lore.kernel.org/lkml/20241107190818.522639-3-ankur.a.arora@oracle.com/ > [2] https://lore.kernel.org/lkml/20250107140004.2732830-9-memxor@gmail.com/ > > -- > Cc: Arnd Bergmann <arnd@arndb.de> > Cc: Will Deacon <will@kernel.org> > Cc: Catalin Marinas <catalin.marinas@arm.com> > Cc: Peter Zijlstra <peterz@infradead.org> > Cc: Kumar Kartikeya Dwivedi <memxor@gmail.com> > Cc: linux-arch@vger.kernel.org > > Ankur Arora (4): > asm-generic: barrier: Add smp_cond_load_relaxed_timewait() > asm-generic: barrier: Add smp_cond_load_acquire_timewait() > arm64: barrier: Add smp_cond_load_relaxed_timewait() > arm64: barrier: Add smp_cond_load_acquire_timewait() > > arch/arm64/include/asm/barrier.h | 74 ++++++++++++++++++++++++++++++++ > include/asm-generic/barrier.h | 71 ++++++++++++++++++++++++++++++ > 2 files changed, 145 insertions(+) -- ankur
On Mon, 3 Feb 2025 at 22:49, Ankur Arora <ankur.a.arora@oracle.com> wrote: > > Hi, > > This series adds waited variants of the smp_cond_load() primitives: > smp_cond_load_relaxed_timewait(), and smp_cond_load_acquire_timewait(). > > There are two known users for these interfaces: > > - poll_idle() [1] > - resilient queued spinlocks [2] > > For both of these cases we want to wait on a condition but also want > to terminate the wait at some point. > > Now, in theory, that can be worked around by making the time check a > part of the conditional expression provided to smp_cond_load_*(): > > smp_cond_load_relaxed(&cvar, !VAL || time_check()); > > That approach, however, runs into two problems: > > - smp_cond_load_*() only allow waiting on a condition: this might > be okay when we are synchronously spin-waiting on the condition, > but not on architectures where are actually waiting for a store > to a cacheline. > > - this semantic problem becomes a real problem on arm64 if the > event-stream is disabled. That means that there will be no > asynchronous event (the event-stream) that periodically wakes > the waiter, which might lead to an interminable wait if VAL is > never written to. > > This series extends the smp_cond_load_*() interfaces by adding two > arguments: a time-check expression and its associated time limit. > This is sufficient to allow for both a synchronously waited > implementation (like the generic cpu_relax() based loop), or one > where the CPU waits for a store to a cacheline with an out-of-band > timer. > > Any comments appreciated! > Thanks for splitting this and sending it out. +cc bpf@ for visibility (please keep it in cc for subsequent versions). > > [...]
Hi folks, Gentle ping for reviews. Next versions of users of this series: Resilient Queued Spin Lock: https://lore.kernel.org/lkml/20250303152305.3195648-1-memxor@gmail.com/ poll_idle(): https://lore.kernel.org/lkml/20250218213337.377987-1-ankur.a.arora@oracle.com/ Thanks Ankur Ankur Arora <ankur.a.arora@oracle.com> writes: > Hi, > > This series adds waited variants of the smp_cond_load() primitives: > smp_cond_load_relaxed_timewait(), and smp_cond_load_acquire_timewait(). > > There are two known users for these interfaces: > > - poll_idle() [1] > - resilient queued spinlocks [2] > > For both of these cases we want to wait on a condition but also want > to terminate the wait at some point. > > Now, in theory, that can be worked around by making the time check a > part of the conditional expression provided to smp_cond_load_*(): > > smp_cond_load_relaxed(&cvar, !VAL || time_check()); > > That approach, however, runs into two problems: > > - smp_cond_load_*() only allow waiting on a condition: this might > be okay when we are synchronously spin-waiting on the condition, > but not on architectures where are actually waiting for a store > to a cacheline. > > - this semantic problem becomes a real problem on arm64 if the > event-stream is disabled. That means that there will be no > asynchronous event (the event-stream) that periodically wakes > the waiter, which might lead to an interminable wait if VAL is > never written to. > > This series extends the smp_cond_load_*() interfaces by adding two > arguments: a time-check expression and its associated time limit. > This is sufficient to allow for both a synchronously waited > implementation (like the generic cpu_relax() based loop), or one > where the CPU waits for a store to a cacheline with an out-of-band > timer. > > Any comments appreciated! > > > Ankur > > [1] https://lore.kernel.org/lkml/20241107190818.522639-3-ankur.a.arora@oracle.com/ > [2] https://lore.kernel.org/lkml/20250107140004.2732830-9-memxor@gmail.com/ > > -- > Cc: Arnd Bergmann <arnd@arndb.de> > Cc: Will Deacon <will@kernel.org> > Cc: Catalin Marinas <catalin.marinas@arm.com> > Cc: Peter Zijlstra <peterz@infradead.org> > Cc: Kumar Kartikeya Dwivedi <memxor@gmail.com> > Cc: linux-arch@vger.kernel.org > > Ankur Arora (4): > asm-generic: barrier: Add smp_cond_load_relaxed_timewait() > asm-generic: barrier: Add smp_cond_load_acquire_timewait() > arm64: barrier: Add smp_cond_load_relaxed_timewait() > arm64: barrier: Add smp_cond_load_acquire_timewait() > > arch/arm64/include/asm/barrier.h | 74 ++++++++++++++++++++++++++++++++ > include/asm-generic/barrier.h | 71 ++++++++++++++++++++++++++++++ > 2 files changed, 145 insertions(+)
© 2016 - 2026 Red Hat, Inc.