From: Lukasz Luba <lukasz.luba@arm.com>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: wyes.karny@amd.com, peterz@infradead.org,
linux-pm@vger.kernel.org, rafael@kernel.org, vschneid@redhat.com,
bristot@redhat.com, bsegall@google.com, rostedt@goodmis.org,
dietmar.eggemann@arm.com, juri.lelli@redhat.com,
beata.michalska@arm.com, linux-kernel@vger.kernel.org,
qyousef@layalina.io, viresh.kumar@linaro.org, mingo@redhat.com,
mgorman@suse.de
Subject: Re: [PATCH v2 1/2] sched/schedutil: rework performance estimation
Date: Mon, 30 Oct 2023 17:46:42 +0000 [thread overview]
Message-ID: <83d6a790-3d18-4922-850b-b60e88761786@arm.com> (raw)
In-Reply-To: <20231026170913.32605-2-vincent.guittot@linaro.org>
Hi Vincent,
On 10/26/23 18:09, Vincent Guittot wrote:
> The current method to take into account uclamp hints when estimating the
> target frequency can end into situation where the selected target
> frequency is finally higher than uclamp hints whereas there are no real
> needs. Such cases mainly happen because we are currently mixing the
> traditional scheduler utilization signal with the uclamp performance
> hints. By adding these 2 metrics, we loose an important information when
> it comes to select the target frequency and we have to make some
> assumptions which can't fit all cases.
>
> Rework the interface between the scheduler and schedutil governor in order
> to propagate all information down to the cpufreq governor.
>
> effective_cpu_util() interface changes and now returns the actual
> utilization of the CPU with 2 optional inputs:
> - The minimum performance for this CPU; typically the capacity to handle
> the deadline task and the interrupt pressure. But also uclamp_min
> request when available.
> - The maximum targeting performance for this CPU which reflects the
> maximum level that we would like to not exceed. By default it will be
> the CPU capacity but can be reduced because of some performance hints
> set with uclamp. The value can be lower than actual utilization and/or
> min performance level.
You have probably missed my question in the last v1 patch set.
The description above needs a bit of clarification, since looking at the
patches some dark corners are introduced IMO:
Currently, we have a less aggressive power saving policy than this
proposal.
The questions:
What if the PD has 4 CPUs, the max util found is 500 and is from a CPU
w/ uclamp_max, but there is another CPU with normal utilization 499?
What should be the final frequency for that PD?
In current design, where we care more about 'delivered performance
to the tasks' than power saving, the +20% would be applied for the
frequency. Therefore if that CPU with 499 util doesn't have uclamp_max,
it would get a decent amount of idle time for its tasks (to compensate
some workload variation).
Regards,
Lukasz
next prev parent reply other threads:[~2023-10-30 17:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-26 17:09 [PATCH v2 0/2] Rework interface between scheduler and schedutil governor Vincent Guittot
2023-10-26 17:09 ` [PATCH v2 1/2] sched/schedutil: rework performance estimation Vincent Guittot
2023-10-30 17:46 ` Lukasz Luba [this message]
2023-10-31 9:48 ` Vincent Guittot
2023-11-16 13:14 ` Lukasz Luba
2023-11-02 12:03 ` Dietmar Eggemann
2023-11-02 12:58 ` Vincent Guittot
2023-10-26 17:09 ` [PATCH v2 2/2] sched/schedutil: rework iowait boost Vincent Guittot
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=83d6a790-3d18-4922-850b-b60e88761786@arm.com \
--to=lukasz.luba@arm.com \
--cc=beata.michalska@arm.com \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=qyousef@layalina.io \
--cc=rafael@kernel.org \
--cc=rostedt@goodmis.org \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@linaro.org \
--cc=vschneid@redhat.com \
--cc=wyes.karny@amd.com \
/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®