Re: [PATCH v11 00/14] barrier: Add smp_cond_load_{relaxed, acquire}_timeout()

["Okanovic, Haris" <harisokn@amazon.com>]

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@linux-foundation.org> writes:
> 
> > On Wed,  8 Apr 2026 17:55:24 +0530 Ankur Arora <ankur.a.arora@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