From: Lukasz Luba <lukasz.luba@arm.com>
To: Roman Kagan <rkagan@amazon.de>
Cc: linux-pm@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org,
Pasha Tatashin <pasha.tatashin@soleen.com>,
Mike Rapoport <rppt@kernel.org>, Pavel Machek <pavel@kernel.org>,
Randy Dunlap <rdunlap@infradead.org>,
Jonathan Corbet <corbet@lwn.net>,
Christian Loehle <christian.loehle@arm.com>,
Pratyush Yadav <pratyush@kernel.org>,
kexec@lists.infradead.org, nh-open-source@amazon.com,
"Rafael J. Wysocki" <rafael@kernel.org>,
Daniel Lezcano <daniel.lezcano@kernel.org>,
Shuah Khan <skhan@linuxfoundation.org>,
Len Brown <lenb@kernel.org>
Subject: Re: [PATCH v2] PM: QoS: Add a sysfs CPU latency request with a boot-time value
Date: Mon, 12 Oct 2026 12:04:33 +0100 [thread overview]
Message-ID: <34106881-8ca0-4c9f-a4d2-0ff0b35460dc@arm.com> (raw)
In-Reply-To: <20261010-b4-cpuidle-shallow-v2-1-adede7dd9077@amazon.de>
On 10/10/26 14:29, Roman Kagan wrote:
> The idle states offered by a platform trade wakeup latency for energy
> savings, and there are situations where the trade is not worth making:
> while a latency-sensitive workload is running, or during a live update
> via kexec, where everything from the outgoing kernel stopping the
> workload to the incoming kernel resuming it is downtime, and deep idle
> states may lengthen it.
>
[snip]
For your scenario, when doing kexec to the new kernel, the normal
disable procedure for idle states for each CPU doesn't work?
You would like to keep this information also in the booting
system (via bootcmd) so the CPUs are still not allowed to go deeper
idle during boot, is that right?
Isn't it FW responsibility?
BTW, I'm not a fun of one global knob for all CPUs. I would
favor extending the usage of the new sysfs and make it per-CPU.
That would allow more scenarios used by user-space daemons at
runtime and not to create yet another sysfs interface.
Regards,
Lukasz
prev parent reply other threads:[~2026-10-12 11:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-10 13:29 Roman Kagan
2026-10-10 13:40 ` sashiko-bot
2026-10-12 10:01 ` Christian Loehle
2026-10-12 11:04 ` Lukasz Luba [this message]
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=34106881-8ca0-4c9f-a4d2-0ff0b35460dc@arm.com \
--to=lukasz.luba@arm.com \
--cc=christian.loehle@arm.com \
--cc=corbet@lwn.net \
--cc=daniel.lezcano@kernel.org \
--cc=kexec@lists.infradead.org \
--cc=lenb@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=nh-open-source@amazon.com \
--cc=pasha.tatashin@soleen.com \
--cc=pavel@kernel.org \
--cc=pratyush@kernel.org \
--cc=rafael@kernel.org \
--cc=rdunlap@infradead.org \
--cc=rkagan@amazon.de \
--cc=rppt@kernel.org \
--cc=skhan@linuxfoundation.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
all inboxes | Powered by JetHome®