On Thu, 10 Jul 2025 08:55:28 +0800Thanks for the advice! I’ll keep that in mind for my next patch.
Zihuan Zhang <zhangzihuan@xxxxxxxxxx> wrote:
The motivation behind this patch is to explore whether it’s worthMy honest opinion is that if there's not a huge issue you are trying
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?
to solve, then it's best to leave things as is. Tweaking this for
micro-optimizations usually end up causing a regression somewhere you
never expected.
-- Steve