From: Christian Loehle <christian.loehle@arm.com>
To: Zihuan Zhang <zhangzihuan@kylinos.cn>,
xuewen.yan@unisoc.com, vincent.guittot@linaro.org,
mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com
Cc: rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
vschneid@redhat.com, hongyan.xia2@arm.com,
linux-kernel@vger.kernel.org, ke.wang@unisoc.com,
di.shen@unisoc.com, xuewen.yan94@gmail.com,
kprateek.nayak@amd.com, kuyo.chang@mediatek.com,
juju.sung@mediatek.com, qyousef@layalina.io
Subject: Re: [PATCH v1] sched/uclamp: Exclude kernel threads from uclamp logic
Date: Thu, 3 Jul 2025 11:17:44 +0100 [thread overview]
Message-ID: <8a64cb22-24f7-4ca7-8e4e-22e1612124d9@arm.com> (raw)
In-Reply-To: <6414cb05-11d3-4b2a-ae97-7bb0ca0ea898@kylinos.cn>
On 7/3/25 11:07, Zihuan Zhang wrote:
> Hi Christian,
>
> Thanks for the question!
>
> 在 2025/7/3 17:22, Christian Loehle 写道:
>> On 7/3/25 10:14, Zihuan Zhang wrote:
>>> Kernel threads (PF_KTHREAD) are not subject to user-defined utilization
>>> clamping. They do not represent user workloads and should not participate
>>> in any uclamp logic, including:
>> Why not?
>>
> As Xuewen mentioned, some kernel threads may intentionally set scheduling attributes for performance. So instead of unconditionally excluding all kernel threads, I’m now considering a more conservative approach:
> skip only those kthreads that haven’t explicitly set any clamp values.
>
> This should help avoid unintended clamp aggregation while still supporting performance-tuned kthreads.
I'm skeptical, fundamentally you cannot exclude some fair tasks from uclamp logic.
At least the cpufreq part they will be affected by, so if you 'exclude' some
kthread that doesn't have clamps set (i.e. has min=0, max=1024) its
utilization may not contribute to sugov frequency selection by being
clamped by other task(s) (let's say you only have one other task with
max=0, excluding the unclamped kthread now leads to sugov requesting
the lowest OPP? Is that always correct/desired?)
Is there a specific issue you're trying to solve?
FYI there has been discussion around reworking the uclamp mechanism to solve
some issues you may have been facing, but so far they haven't lead anywhere:
https://lore.kernel.org/lkml/cover.1741091349.git.hongyan.xia2@arm.com/
next prev parent reply other threads:[~2025-07-03 10:17 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-03 9:14 Zihuan Zhang
2025-07-03 9:22 ` Christian Loehle
2025-07-03 10:07 ` Zihuan Zhang
2025-07-03 10:17 ` Christian Loehle [this message]
2025-07-10 0:47 ` Zihuan Zhang
2025-07-10 3:41 ` K Prateek Nayak
2025-07-15 6:05 ` Zihuan Zhang
2025-07-10 8:41 ` Christian Loehle
2025-07-15 5:54 ` Zihuan Zhang
2025-07-03 14:51 ` Steven Rostedt
2025-07-10 0:55 ` Zihuan Zhang
2025-07-10 14:03 ` Steven Rostedt
2025-07-15 5:59 ` Zihuan Zhang
2025-07-03 9:42 ` Xuewen Yan
2025-07-03 10:14 ` Zihuan Zhang
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=8a64cb22-24f7-4ca7-8e4e-22e1612124d9@arm.com \
--to=christian.loehle@arm.com \
--cc=bsegall@google.com \
--cc=di.shen@unisoc.com \
--cc=hongyan.xia2@arm.com \
--cc=juju.sung@mediatek.com \
--cc=juri.lelli@redhat.com \
--cc=ke.wang@unisoc.com \
--cc=kprateek.nayak@amd.com \
--cc=kuyo.chang@mediatek.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=qyousef@layalina.io \
--cc=rostedt@goodmis.org \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=xuewen.yan94@gmail.com \
--cc=xuewen.yan@unisoc.com \
--cc=zhangzihuan@kylinos.cn \
/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®