Sudeep Holla <sudeep.holla@xxxxxxx> 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
