Re: [PATCH 8/9] arm64: support cpuidle-haltpoll

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

Sudeep Holla <sudeep.holla@arm.com> writes:

> On Tue, Apr 30, 2024 at 11:37:29AM -0700, Ankur Arora wrote:
>> Add architectural support for the cpuidle-haltpoll driver by defining
>> arch_haltpoll_*(). Also select ARCH_HAS_OPTIMIZED_POLL since we have
>> an optimized polling mechanism via smp_cond_load*().
>>
>> Add the configuration option, ARCH_CPUIDLE_HALTPOLL to allow
>> cpuidle-haltpoll to be selected.
>>
>> Note that we limit cpuidle-haltpoll support to when the event-stream is
>> available. This is necessary because polling via smp_cond_load_relaxed()
>> uses WFE to wait for a store which might not happen for an prolonged
>> period of time. So, ensure the event-stream is around to provide a
>> terminating condition.
>>
>
> Currently the event stream is configured 10kHz(1 signal per 100uS IIRC).
> But the information in the cpuidle states for exit latency and residency
> is set to 0(as per drivers/cpuidle/poll_state.c). Will this not cause any
> performance issues ?

No I don't think there's any performance issue.

When the core is waiting in WFE for &thread_info->flags to
change, and set_nr_if_polling() happens, the CPU will come out
of the wait quickly.
So, the exit latency, residency can be reasonably set to 0.

If, however, there is no store to &thread_info->flags, then the event
stream is what would cause us to come out of the WFE and check if
the poll timeout has been exceeded.
In that case, there was no work to be done, so there was nothing
to wake up from.

So, in either circumstance there's no performance loss.

However, when we are polling under the haltpoll governor, this might
mean that we spend more time polling than determined based on the
guest_halt_poll_ns. But, that would only happen in the last polling
iteration.

So, I'd say, at worst no performance loss. But, we would sometimes
poll for longer than necessary before exiting to the host.

--
ankur