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

[Ankur Arora <ankur.a.arora@oracle.com>]

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.

--
ankur