From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Kevin Hilman <khilman@kernel.org>,
Ulf Hansson <ulf.hansson@linaro.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Lorenzo Pieralisi <lpieralisi@kernel.org>,
Sudeep Holla <sudeep.holla@arm.com>,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Adrien Thierry <athierry@redhat.com>,
Brian Masney <bmasney@redhat.com>,
linux-rt-users@vger.kernel.org
Subject: Re: [PATCH v2 3/5] cpuidle: psci: Do not suspend topology CPUs on PREEMPT_RT
Date: Mon, 30 Jan 2023 10:51:33 +0100 [thread overview]
Message-ID: <Y9eTJVkyp3iiiYpK@linutronix.de> (raw)
In-Reply-To: <3d7c3a52-baa4-ce7b-e6d1-06a4d885d445@linaro.org>
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
next prev parent reply other threads:[~2023-01-30 9:52 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-19 15:14 [PATCH v2 0/5] PM: Fixes for Realtime systems Krzysztof Kozlowski
2022-12-19 15:14 ` [PATCH v2 1/5] PM: domains: Add GENPD_FLAG_RT_SAFE for PREEMPT_RT Krzysztof Kozlowski
2023-01-04 15:45 ` Ulf Hansson
2023-01-06 14:52 ` Krzysztof Kozlowski
2023-01-12 10:36 ` Sebastian Andrzej Siewior
2023-01-12 11:27 ` Krzysztof Kozlowski
2023-01-12 10:32 ` Sebastian Andrzej Siewior
2023-01-12 11:31 ` Krzysztof Kozlowski
2022-12-19 15:15 ` [PATCH v2 2/5] cpuidle: psci: Mark as PREEMPT_RT safe Krzysztof Kozlowski
2023-01-12 11:00 ` Sebastian Andrzej Siewior
2023-01-12 11:32 ` Krzysztof Kozlowski
2023-01-17 15:27 ` Ulf Hansson
2023-01-19 15:40 ` Krzysztof Kozlowski
2023-01-19 17:06 ` Krzysztof Kozlowski
2022-12-19 15:15 ` [PATCH v2 3/5] cpuidle: psci: Do not suspend topology CPUs on PREEMPT_RT Krzysztof Kozlowski
2023-01-12 11:09 ` Sebastian Andrzej Siewior
2023-01-12 11:34 ` Krzysztof Kozlowski
2023-01-30 9:51 ` Sebastian Andrzej Siewior [this message]
2022-12-19 15:15 ` [PATCH v2 4/5] PM: Allow calling dev_pm_domain_set() with raw spinlock Krzysztof Kozlowski
2023-01-12 11:13 ` Sebastian Andrzej Siewior
2022-12-19 15:15 ` [PATCH v2 5/5] PM: domains: Do not call device_pm_check_callbacks() when holding genpd_lock() Krzysztof Kozlowski
2023-01-12 11:31 ` Sebastian Andrzej Siewior
2023-01-12 11:37 ` Krzysztof Kozlowski
2023-01-17 15:11 ` Ulf Hansson
2023-01-19 15:58 ` Krzysztof Kozlowski
2022-12-20 21:36 ` [PATCH v2 0/5] PM: Fixes for Realtime systems Adrien Thierry
2023-01-04 15:15 ` Ulf Hansson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y9eTJVkyp3iiiYpK@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=athierry@redhat.com \
--cc=bmasney@redhat.com \
--cc=daniel.lezcano@linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=khilman@kernel.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=len.brown@intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=pavel@ucw.cz \
--cc=rafael@kernel.org \
--cc=sudeep.holla@arm.com \
--cc=ulf.hansson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).