[PATCH v11 12/14] cpuidle/poll_state: Wait for need-resched via tif_need_resched_relaxed_wait()
Catalin Marinas
catalin.marinas at arm.com
Tue Apr 21 00:15:07 PDT 2026
On Mon, Apr 20, 2026 at 10:50:08AM -0700, Ankur Arora wrote:
> Okanovic, Haris <harisokn at amazon.com> writes:
> > On Wed, 2026-04-08 at 17:55 +0530, Ankur Arora wrote:
> >> The inner loop in poll_idle() polls over the thread_info flags,
> >> waiting to see if the thread has TIF_NEED_RESCHED set. The loop
> >> exits once the condition is met, or if the poll time limit has
> >> been exceeded.
> >>
> >> To minimize the number of instructions executed in each iteration,
> >> the time check is rate-limited. In addition, each loop iteration
> >> executes cpu_relax() which on certain platforms provides a hint to
> >> the pipeline that the loop busy-waits, allowing the processor to
> >> reduce power consumption.
> >>
> >> Switch over to tif_need_resched_relaxed_wait() instead, since that
> >> provides exactly that.
> >>
> >> However, since we want to minimize power consumption in idle, building
> >> of cpuidle/poll_state.c continues to depend on CONFIG_ARCH_HAS_CPU_RELAX
> >> as that serves as an indicator that the platform supports an optimized
> >> version of tif_need_resched_relaxed_wait() (via
> >> smp_cond_load_acquire_timeout()).
> >>
> >> Cc: Rafael J. Wysocki <rafael at kernel.org>
> >> Cc: Daniel Lezcano <daniel.lezcano at linaro.org>
> >> Cc: linux-pm at vger.kernel.org
> >> Suggested-by: Rafael J. Wysocki <rafael at kernel.org>
> >> Acked-by: Rafael J. Wysocki (Intel) <rafael at kernel.org>
> >> Signed-off-by: Ankur Arora <ankur.a.arora at oracle.com>
[...]
> > Tested atop latest mainline d60bc1401 with the rest of your haltpoll
> > changes from separate thread: ~10% improvement in `perf sched bench
> > pipe` micro and ~4-6% throughput improvements in mysql, postgresql,
> > cassandra, and memcached in under-loaded configurations. Tested on
> > AWS Graviton3 and Graviton4, ARM Neoverse V1 and V2 cores
> > respectively.
> >
> > I hope this series can merge soon. It's been stuck in review for more
> > than 2 years.
> >
> > Tested-by: Haris Okanovic <harisokn at amazon.com>
>
> Thanks Haris. Yeah, I don't think there are any open issues left on
> this.
I agree, though an ack from the atomic infrastructure people on the
generic bits would be nice.
--
Catalin
More information about the linux-arm-kernel
mailing list