[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6414cb05-11d3-4b2a-ae97-7bb0ca0ea898@kylinos.cn>
Date: Thu, 3 Jul 2025 18:07:20 +0800
From: Zihuan Zhang <zhangzihuan@...inos.cn>
To: Christian Loehle <christian.loehle@....com>, xuewen.yan@...soc.com,
vincent.guittot@...aro.org, mingo@...hat.com, peterz@...radead.org,
juri.lelli@...hat.com
Cc: rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de,
vschneid@...hat.com, hongyan.xia2@....com, linux-kernel@...r.kernel.org,
ke.wang@...soc.com, di.shen@...soc.com, xuewen.yan94@...il.com,
kprateek.nayak@....com, kuyo.chang@...iatek.com, juju.sung@...iatek.com,
qyousef@...alina.io
Subject: Re: [PATCH v1] sched/uclamp: Exclude kernel threads from uclamp logic
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.
>> [snip]
Best regards,
Zihuan
Powered by blists - more mailing lists