From: Ankur Arora <ankur.a.arora@oracle.com>
To: Ankur Arora <ankur.a.arora@oracle.com>
Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, arnd@arndb.de,
catalin.marinas@arm.com, will@kernel.org, peterz@infradead.org,
mark.rutland@arm.com, harisokn@amazon.com, cl@gentwo.org,
memxor@gmail.com, zhenglifeng1@huawei.com,
joao.m.martins@oracle.com, boris.ostrovsky@oracle.com,
konrad.wilk@oracle.com
Subject: Re: [PATCH 0/4] barrier: Introduce smp_cond_load_*_timeout()
Date: Tue, 18 Feb 2025 13:48:14 -0800 [thread overview]
Message-ID: <871pvu3owx.fsf@oracle.com> (raw)
In-Reply-To: <20250203214911.898276-1-ankur.a.arora@oracle.com>
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
next prev parent reply other threads:[~2025-02-18 21:48 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-03 21:49 [PATCH 0/4] barrier: Introduce smp_cond_load_*_timeout() Ankur Arora
2025-02-03 21:49 ` [PATCH 1/4] asm-generic: barrier: Add smp_cond_load_relaxed_timewait() Ankur Arora
2025-03-04 19:15 ` Catalin Marinas
2025-03-06 7:53 ` Ankur Arora
2025-03-11 8:48 ` Kumar Kartikeya Dwivedi
2025-03-12 6:34 ` Ankur Arora
2025-03-09 3:26 ` Ankur Arora
2025-02-03 21:49 ` [PATCH 2/4] asm-generic: barrier: Add smp_cond_load_acquire_timewait() Ankur Arora
2025-02-03 21:49 ` [PATCH 3/4] arm64: barrier: Add smp_cond_load_relaxed_timewait() Ankur Arora
2025-03-04 19:29 ` Catalin Marinas
2025-03-06 7:58 ` Ankur Arora
2025-02-03 21:49 ` [PATCH 4/4] arm64: barrier: Add smp_cond_load_acquire_timewait() Ankur Arora
2025-02-14 22:42 ` Okanovic, Haris
2025-02-18 21:44 ` Ankur Arora
2025-02-06 10:57 ` [PATCH 0/4] barrier: Introduce smp_cond_load_*_timeout() Kumar Kartikeya Dwivedi
2025-02-18 21:48 ` Ankur Arora [this message]
2025-03-03 21:28 ` 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=871pvu3owx.fsf@oracle.com \
--to=ankur.a.arora@oracle.com \
--cc=arnd@arndb.de \
--cc=boris.ostrovsky@oracle.com \
--cc=catalin.marinas@arm.com \
--cc=cl@gentwo.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=mark.rutland@arm.com \
--cc=memxor@gmail.com \
--cc=peterz@infradead.org \
--cc=will@kernel.org \
--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.