mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: K Prateek Nayak <kprateek.nayak@amd.com>
To: Zihuan Zhang <zhangzihuan@kylinos.cn>,
	Christian Loehle <christian.loehle@arm.com>,
	xuewen.yan@unisoc.com, vincent.guittot@linaro.org,
	mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com
Cc: rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
	vschneid@redhat.com, hongyan.xia2@arm.com,
	linux-kernel@vger.kernel.org, ke.wang@unisoc.com,
	di.shen@unisoc.com, xuewen.yan94@gmail.com,
	kuyo.chang@mediatek.com, juju.sung@mediatek.com,
	qyousef@layalina.io
Subject: Re: [PATCH v1] sched/uclamp: Exclude kernel threads from uclamp logic
Date: Thu, 10 Jul 2025 09:11:27 +0530	[thread overview]
Message-ID: <fb97657e-cb61-4e8d-a156-eb1141dce19e@amd.com> (raw)
In-Reply-To: <386d99d3-aa97-4069-8d63-d197262832bf@kylinos.cn>

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


  reply	other threads:[~2025-07-10  3:41 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-03  9:14 Zihuan Zhang
2025-07-03  9:22 ` Christian Loehle
2025-07-03 10:07   ` Zihuan Zhang
2025-07-03 10:17     ` Christian Loehle
2025-07-10  0:47       ` Zihuan Zhang
2025-07-10  3:41         ` K Prateek Nayak [this message]
2025-07-15  6:05           ` Zihuan Zhang
2025-07-10  8:41         ` Christian Loehle
2025-07-15  5:54           ` Zihuan Zhang
2025-07-03 14:51     ` Steven Rostedt
2025-07-10  0:55       ` Zihuan Zhang
2025-07-10 14:03         ` Steven Rostedt
2025-07-15  5:59           ` Zihuan Zhang
2025-07-03  9:42 ` Xuewen Yan
2025-07-03 10:14   ` Zihuan Zhang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fb97657e-cb61-4e8d-a156-eb1141dce19e@amd.com \
    --to=kprateek.nayak@amd.com \
    --cc=bsegall@google.com \
    --cc=christian.loehle@arm.com \
    --cc=di.shen@unisoc.com \
    --cc=hongyan.xia2@arm.com \
    --cc=juju.sung@mediatek.com \
    --cc=juri.lelli@redhat.com \
    --cc=ke.wang@unisoc.com \
    --cc=kuyo.chang@mediatek.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=qyousef@layalina.io \
    --cc=rostedt@goodmis.org \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    --cc=xuewen.yan94@gmail.com \
    --cc=xuewen.yan@unisoc.com \
    --cc=zhangzihuan@kylinos.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®