[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240619121711.jid3enfzak7vykyn@bogus>
Date: Wed, 19 Jun 2024 13:17:11 +0100
From: Sudeep Holla <sudeep.holla@....com>
To: Ankur Arora <ankur.a.arora@...cle.com>
Cc: linux-pm@...r.kernel.org, kvm@...r.kernel.org,
Sudeep Holla <sudeep.holla@....com>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
catalin.marinas@....com, will@...nel.org, tglx@...utronix.de,
mingo@...hat.com, bp@...en8.de, x86@...nel.org, hpa@...or.com,
pbonzini@...hat.com, wanpengli@...cent.com, vkuznets@...hat.com,
rafael@...nel.org, daniel.lezcano@...aro.org, peterz@...radead.org,
arnd@...db.de, lenb@...nel.org, mark.rutland@....com,
harisokn@...zon.com, joao.m.martins@...cle.com,
boris.ostrovsky@...cle.com, konrad.wilk@...cle.com
Subject: Re: [PATCH 8/9] arm64: support cpuidle-haltpoll
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 ?
--
Regards,
Sudeep
Powered by blists - more mailing lists