linux-kernel - Re: [PATCH v3] cpuidle: psci: Do not suspend topology CPUs on PREEMPT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPDyKFrS6OER2h3XmHMfbjBA09HT8LYN9A90TPjd0RPim3jMaw@mail.gmail.com>
Date:   Wed, 25 Jan 2023 11:08:04 +0100
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Sudeep Holla <sudeep.holla@....com>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Lorenzo Pieralisi <lpieralisi@...nel.org>,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Adrien Thierry <athierry@...hat.com>,
        Brian Masney <bmasney@...hat.com>,
        linux-rt-users@...r.kernel.org
Subject: Re: [PATCH v3] cpuidle: psci: Do not suspend topology CPUs on PREEMPT_RT

On Wed, 25 Jan 2023 at 08:43, Krzysztof Kozlowski
<krzysztof.kozlowski@...aro.org> wrote:
>
> On 24/01/2023 16:34, Sudeep Holla wrote:
> > On Thu, Jan 19, 2023 at 07:42:28PM +0100, Krzysztof Kozlowski wrote:
> >> The runtime Power Management of CPU topology is not compatible with
> >> PREEMPT_RT:
> >> 1. Core cpuidle path disables IRQs.
> >> 2. Core cpuidle calls cpuidle-psci.
> >> 3. cpuidle-psci in __psci_enter_domain_idle_state() calls
> >>    pm_runtime_put_sync_suspend() and pm_runtime_get_sync() which use
> >>    spinlocks (which are sleeping on PREEMPT_RT).
> >>
> >> Deep sleep modes are not a priority of Realtime kernels because the
> >> latencies might become unpredictable.  On the other hand the PSCI CPU
> >> idle power domain is a parent of other devices and power domain
> >> controllers, thus it cannot be simply skipped (e.g. on Qualcomm SM8250).
> >>
> >> Disable the runtime PM calls from cpuidle-psci, which effectively stops
> >> suspending the cpuidle PSCI domain.  This is a trade-off between making
> >> PREEMPT_RT working and still having a proper power domain hierarchy in
> >> the system.
> >>
> >> Cc: Adrien Thierry <athierry@...hat.com>
> >> Cc: Brian Masney <bmasney@...hat.com>
> >> Cc: linux-rt-users@...r.kernel.org
> >> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
> >>
> >> ---
> >>
> >> Changes since v1:
> >> 1. Re-work commit msg.
> >> 2. Add note to Kconfig.
> >>
> >> Several other patches were dropped, as this is the only one actually
> >> needed.  It effectively stops PSCI cpuidle power domains from suspending
> >> thus solving all other issues I experienced.
> >> ---
> >>  drivers/cpuidle/Kconfig.arm    | 3 +++
> >>  drivers/cpuidle/cpuidle-psci.c | 4 ++--
> >>  2 files changed, 5 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/cpuidle/Kconfig.arm b/drivers/cpuidle/Kconfig.arm
> >> index 747aa537389b..24429b5bfd1c 100644
> >> --- a/drivers/cpuidle/Kconfig.arm
> >> +++ b/drivers/cpuidle/Kconfig.arm
> >> @@ -24,6 +24,9 @@ config ARM_PSCI_CPUIDLE
> >>        It provides an idle driver that is capable of detecting and
> >>        managing idle states through the PSCI firmware interface.
> >>
> >> +      The driver is not yet compatible with PREEMPT_RT: no idle states will
> >> +      be entered by CPUs on such kernel.
> >> +
> >
> > Any particular reason for even compiling this file in or allowing the
> > ARM_PSCI_CPUIDLE when PREEMPT_RT=y ? If we can't enter idle states, we
> > can as well compile this file out ?
>
> It's the power domain sued for other devices, so we need it. Otherwise
> other devices will keep waiting for this missing power domain provider.

Yes.

And we are still able to use those idle states that are solely per
CPU, which is probably nice to have. No?

Kind regards
Uffe