From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Linux PM <linux-pm@vger.kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Viresh Kumar <viresh.kumar@linaro.org>,
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
Mario Limonciello <mario.limonciello@amd.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Christian Loehle <christian.loehle@arm.com>,
Sultan Alsawaf <sultan@kerneltoast.com>,
Peter Zijlstra <peterz@infradead.org>,
Valentin Schneider <vschneid@redhat.com>,
Ingo Molnar <mingo@redhat.com>
Subject: [PATCH v1 0/5] cpufreq/sched: Improve synchronization of policy limits updates with schedutil
Date: Mon, 14 Apr 2025 22:39:53 +0200 [thread overview]
Message-ID: <3364921.aeNJFYEL58@rjwysocki.net> (raw)
Hi Everyone,
This series of patches has been inspired by the discussion following a bug
report regarding the patch at
https://lore.kernel.org/lkml/20241212015734.41241-2-sultan@kerneltoast.com/
and its attempted unsuccessful resolution:
https://lore.kernel.org/linux-pm/20250410024439.20859-1-sultan@kerneltoast.com/
which basically leads to the conclusion that cpufreq policy limits updates are
not sufficiently synchronized with the scheditil governor, especially in the
fast switching case in which running the driver callback is the only way to
make the new policy limits take effect.
The purpose of this series is to address this concern.
Patch [1/5] is a fix for the issue introduced by the patch linked above (please
see the patch changelog for details), for 6.15-rc. The remaining patches are
for 6.16.
Patch [2/5] adds memory barriers in two places in schedutil along with some
WRITE_ONCE()/READ_ONCE() annotations to ensure that policy limits updates will
not be missed due to reordering of instructions.
Patch [3/5] is a preparatory function rename with no functional impact.
Patch [4/5] updates the cpufreq core to avoid situations in which
cpufreq_driver_resolve_freq(), called by schedutil, may see intermediate
values of policy->min and policy->max and makes that function address the
unlikely case in which it may see policy->min > policy->max.
Patch [5/5] cleans up the code after the previous changes.
Please see individual patch changelogs for details.
Thanks!
next reply other threads:[~2025-04-14 20:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-14 20:39 Rafael J. Wysocki [this message]
2025-04-14 20:41 ` [PATCH v1 1/5] cpufreq/sched: Check fast_switch_enabled when setting need_freq_update Rafael J. Wysocki
2025-04-15 9:12 ` Rafael J. Wysocki
2025-04-14 20:45 ` [PATCH v1 2/5] cpufreq/sched: Explicitly synchronize limits_changed flag handling Rafael J. Wysocki
2025-04-14 20:46 ` [PATCH v1 3/5] cpufreq: Rename __resolve_freq() to clamp_and_resolve_freq() Rafael J. Wysocki
2025-04-14 20:50 ` [PATCH v1 4/5] cpufreq: Avoid inconsistent policy->min and policy->max Rafael J. Wysocki
2025-04-14 20:51 ` [PATCH v1 5/5] cpufreq: Eliminate clamp_and_resolve_freq() Rafael J. Wysocki
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=3364921.aeNJFYEL58@rjwysocki.net \
--to=rjw@rjwysocki.net \
--cc=christian.loehle@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=sultan@kerneltoast.com \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@linaro.org \
--cc=vschneid@redhat.com \
/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®