[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fb97657e-cb61-4e8d-a156-eb1141dce19e@amd.com>
Date: Thu, 10 Jul 2025 09:11:27 +0530
From: K Prateek Nayak <kprateek.nayak@....com>
To: Zihuan Zhang <zhangzihuan@...inos.cn>,
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,
kuyo.chang@...iatek.com, juju.sung@...iatek.com, qyousef@...alina.io
Subject: Re: [PATCH v1] sched/uclamp: Exclude kernel threads from uclamp logic
Hello Zihuan,
On 7/10/2025 6:17 AM, Zihuan Zhang wrote:
> - For kernel threads that do not set any clamp values, skip the clamp
> aggregation step
>
> - If a kernel thread explicitly sets clamp attributes, it should of
> course remain fully visible to uclamp logic.
There are also sched_util_clamp_{min,max} global controls via sysctl
which can be influencing the kthread scheduling / freq behavior
indirectly and glancing at the implementation, I think these are
still handled by clamping in uclamp_eff_get() and effective_cpu_util()
only looks at uclamp_rq_get() to make freq decisions.
Wouldn't excluding the kthreads from the uclamp aggregation also change
this behavior? I'm assuming these global knobs can be used to limit
frequencies when thermal throttle is detected and be reset again once
the SoC falls below the throttle limits?
--
Thanks and Regards,
Prateek
Powered by blists - more mailing lists