[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Y9eTJVkyp3iiiYpK@linutronix.de>
Date: Mon, 30 Jan 2023 10:51:33 +0100
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>,
Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Kevin Hilman <khilman@...nel.org>,
Ulf Hansson <ulf.hansson@...aro.org>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Lorenzo Pieralisi <lpieralisi@...nel.org>,
Sudeep Holla <sudeep.holla@....com>, linux-pm@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
Adrien Thierry <athierry@...hat.com>,
Brian Masney <bmasney@...hat.com>,
linux-rt-users@...r.kernel.org
Subject: Re: [PATCH v2 3/5] cpuidle: psci: Do not suspend topology CPUs on
PREEMPT_RT
On 2023-01-12 12:34:35 [+0100], Krzysztof Kozlowski wrote:
> On 12/01/2023 12:09, Sebastian Andrzej Siewior wrote:
> > On 2022-12-19 16:15:01 [+0100], Krzysztof Kozlowski wrote:
> >> diff --git a/drivers/cpuidle/cpuidle-psci.c b/drivers/cpuidle/cpuidle-psci.c
> >> index 57bc3e3ae391..9d971cc4b12b 100644
> >> --- a/drivers/cpuidle/cpuidle-psci.c
> >> +++ b/drivers/cpuidle/cpuidle-psci.c
> >> @@ -72,7 +72,7 @@ static int __psci_enter_domain_idle_state(struct cpuidle_device *dev,
> >> ct_irq_enter_irqson();
> >> if (s2idle)
> >> dev_pm_genpd_suspend(pd_dev);
> >> - else
> >> + else if (!IS_ENABLED(CONFIG_PREEMPT_RT))
> >> pm_runtime_put_sync_suspend(pd_dev);
> >
> > So based on the commit description you run into a sleeping lock in
> > pm_runtime_put_sync_suspend() while the CPU is in an IRQ-off region.
> > Why is it okay to skip it on PREEMPT_RT?
>
> It is okay to skip it everywhere, you just don't get a suspended CPU.
> Why PREEMPT_RT is different here - having suspended CPU is a great way
> to have longer or even unpredictable (as it goes to firmware which is
> out of control of Linux) latencies.
On X86 C1 has a latency of less than 5us and this is exposed by the
firmware. C1E and everything that follows has a much higher entry/ exit
latency which makes not usable.
The entry/exit latency seems not to be exposed by PSCI. My understanding
is that the driver is now enabled but not doing any suspending, right?
If so, why isn't it completely disabled?
> Best regards,
> Krzysztof
Sebastian
Powered by blists - more mailing lists