linux-kernel - Re: [PATCH v1] sched/uclamp: Exclude kernel threads from uclamp logic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <554d1da1-8b35-489c-973d-b5d5dba31403@kylinos.cn>
Date: Thu, 10 Jul 2025 08:55:28 +0800
From: Zihuan Zhang <zhangzihuan@...inos.cn>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Christian Loehle <christian.loehle@....com>, xuewen.yan@...soc.com,
 vincent.guittot@...aro.org, mingo@...hat.com, peterz@...radead.org,
 juri.lelli@...hat.com, 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 Steven,

Thanks for the feedback!

在 2025/7/3 22:51, Steven Rostedt 写道:
> On Thu, 3 Jul 2025 18:07:20 +0800
> Zihuan Zhang <zhangzihuan@...inos.cn> wrote:
>
>> 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.
> The above comment bothers me. What kernel threads set scheduling attributes?
>
>  From my experience working on real-time, no kernel thread gets
> scheduling tweaking correct.
>
> -- Steve

You raised a good point — in most cases, kernel threads don’t explicitly 
tweak scheduling attributes, and when they do, it might not always be 
correct or effective. I appreciate the insight from your real-time 
experience.

The motivation behind this patch is to explore whether it’s worth 
optimizing the uclamp hot path a bit further. Since kernel threads 
typically don’t benefit from uclamp adjustments and often just inherit 
default values (e.g., max=1024), we were wondering if skipping the 
aggregation logic for such cases could slightly reduce overhead in some 
workloads.

Of course, we want to be conservative and avoid breaking any legitimate 
usage. So I’d love to hear your opinion — do you think it’s worthwhile 
to pursue this kind of micro-optimization in uclamp, or is the potential 
gain too marginal to justify the added logic?

Thanks again for your time and thoughts!

Best regards,
Zihuan Zhang