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

[Zihuan Zhang <zhangzihuan@kylinos.cn>]

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@kylinos.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