[PATCH v11 00/14] barrier: Add smp_cond_load_{relaxed, acquire}_timeout()
Okanovic, Haris
harisokn at amazon.com
Fri Apr 24 07:16:52 PDT 2026
On Thu, 2026-04-23 at 12:29 -0700, Ankur Arora wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> Andrew Morton <akpm at linux-foundation.org> writes:
>
> > On Wed, 8 Apr 2026 17:55:24 +0530 Ankur Arora <ankur.a.arora at oracle.com> wrote:
> >
> > > The core kernel often uses smp_cond_load_{relaxed,acquire}() to spin
> > > on condition variables with architectural primitives used to avoid
> > > hammering the relevant cachelines.
> > >
> > > ...
> > >
> > > Accordingly add two interfaces (with their generic and arm64 specific
> > > implementations):
> > >
> > > smp_cond_load_relaxed_timeout(ptr, cond_expr, time_expr, timeout)
> > > smp_cond_load_acquire_timeout(ptr, cond_expr, time_expr, timeout)
> > >
> > > Also add tif_need_resched_relaxed_wait() which wraps the polling
> > > pattern and its scheduler specific details in poll_idle().
> > > In addition add atomic_cond_read_*_timeout(),
> >
> > Thanks, I'll add this to mm.git's mm-new branch today.
>
> Great. Thanks!
>
> > This isn't am MM patchset, but mm-new isn't included in linux-next, and
> > linux-next isn't presently open for 7.1 material.
> >
> > After -rc1 I'll move the series into mm.git's mm-nonmm-unstable branch,
> > where it will get linux-next exposure.
>
> Ack that.
>
> > I see that further review/comment has been requested - hopefully this
> > will happen over the next couple of months, but please do continue to
> > chase this down if you feel the need.
>
> Will do.
>
> > > Haris Okanovic also saw improvement in real workloads due to the
> > > cpuidle changes: "observed 4-6% improvements in memcahed, cassandra,
> > > mysql, and postgresql under certain loads. Other applications likely
> > > benefit too." [12]
> >
> > Those are significant improvements. Three years :(
>
> Part of the reason was that the barrier interface was part of a series
> focused on virtualization via cpuidle-haltpoll. As that was reviewed,
> the tale changed in the telling, and it made more sense to separate
> the two.
>
> Will send out the cpuidle changes for review which Haris is running
> with.
It needs some minor refactors for latest maintain.
This is what I tested last week:
https://github.com/harisokanovic/linux/tree/dev/harisokn/arm-haltpoll-2026-april-test
>
> --
> ankur
Regards,
Haris Okanovic
AWS Graviton Software
More information about the linux-arm-kernel
mailing list