From: Qais Yousef <qyousef@layalina.io>
To: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Viresh Kumar <viresh.kumar@linaro.org>,
Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
Vincent Guittot <vincent.guittot@linaro.org>,
Lukasz Luba <lukasz.luba@arm.com>
Subject: Re: [PATCH RFC 4/4] sched: cpufreq: Apply DVFS headroom to CFS only
Date: Sat, 26 Aug 2023 21:27:11 +0100 [thread overview]
Message-ID: <20230826202711.n73r5wcpibdoiiba@airbuntu> (raw)
In-Reply-To: <7fdfff24-80ed-acbf-810f-b641570141fd@arm.com>
On 08/21/23 18:41, Dietmar Eggemann wrote:
> On 20/08/2023 23:06, Qais Yousef wrote:
> > RT and Deadline have exact performance requirement when running. RT runs
> > at max or a specific OPP defined by uclamp_min. Deadline's OPP is
> > defined by its bandwidth. Both of which are known ahead of time and
> > don't require a headroom to grow into.
> >
> > IRQs on the other hand have no specific performance requirement and
> > cruises along at whatever the current OPP happens to be when they occur.
> >
> > Now they all have PELT pressure signals that does impact frequency
> > selection and task placement. The question is do they need DVFS
> > headroom?
> >
> > I think the answer is no because when CFS is not running at all, these
> > pressure signal has no real impact on performance for RT, DL or IRQ.
> >
> > If CFS util is not zero, we already add their pressure as an
> > *additional* headroom to account for the lost/stolen time. So I argue
> > that the pressure are headroom themselves and shouldn't need an
> > additional DVFS headroom applied on top.
> >
> > In summary final outcome should be:
> >
> > CFS + DVFS headroom + (RT, DT, IRQ) pressure headroom
>
> I assume here you want to align the difference that EAS deals with
This function is used on all systems that use schedutil - EAS being one of them
but not the only one. The definition isn't, and shouldn't, be tied to EAS.
I'm certainly intending this change for all possible users of schedutil.
> `util_cfs` vs `capacity` whereas power deals with `util` vs
> `capacity_orig`? You want that power should only apply the 1.25 to util_cfs?
I don't get what you're saying. But I think it's similar to what I'm saying.
To clarify. What I'm saying is that when we try to calculate the effective
util, CFS is the only entity in practice that interacts with DVFS. DL and RT by
design 'disable' DVFS and when they become runnable set the frequency to
a constant fixed point. For them DVFS latencies are not acceptable - although
in practice they do take a single hit for the freq change on wake up. IRQ on
the other hand doesn't really care about DVFS. So we end up in practice that
CFS is the only entity that interacts with DVFS, so when we calculate the
DVFS headroom, we should only take its util into account.
Thanks!
--
Qais Yousef
next prev parent reply other threads:[~2023-08-26 20:27 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-20 21:06 [PATCH 0/4] Fix dvfs_headroom escaping uclamp constraints Qais Yousef
2023-08-20 21:06 ` [PATCH 1/4] sched: cpufreq: Rename map_util_perf to apply_dvfs_headroom Qais Yousef
2023-08-20 21:13 ` Qais Yousef
2023-08-21 16:38 ` Dietmar Eggemann
2023-08-26 20:03 ` Qais Yousef
2023-08-20 21:06 ` [PATCH 2/4] sched: cpufreq: Fix apply_dvfs_headroom() escaping uclamp constraints Qais Yousef
2023-08-21 16:39 ` Dietmar Eggemann
2023-08-26 20:08 ` Qais Yousef
2023-09-12 14:34 ` Dietmar Eggemann
2023-09-16 20:30 ` Qais Yousef
2023-08-29 14:35 ` Vincent Guittot
2023-08-29 16:37 ` Qais Yousef
2023-09-07 13:47 ` Vincent Guittot
2023-09-07 21:55 ` Qais Yousef
2023-09-08 14:30 ` Vincent Guittot
2023-09-10 17:46 ` Qais Yousef
2023-09-12 13:40 ` Dietmar Eggemann
2023-09-16 19:25 ` Qais Yousef
2023-09-12 16:03 ` Vincent Guittot
2023-09-16 19:25 ` Qais Yousef
2023-09-24 7:58 ` Vincent Guittot
2023-09-24 17:23 ` Qais Yousef
2023-09-28 17:50 ` Vincent Guittot
2023-09-28 22:05 ` Qais Yousef
2023-09-29 8:01 ` Vincent Guittot
2023-08-20 21:06 ` [PATCH 3/4] sched: cpufreq: Move apply_dvfs_headroom() to sched.h Qais Yousef
2023-08-21 16:40 ` Dietmar Eggemann
2023-08-20 21:06 ` [PATCH RFC 4/4] sched: cpufreq: Apply DVFS headroom to CFS only Qais Yousef
2023-08-21 16:41 ` Dietmar Eggemann
2023-08-26 20:27 ` Qais Yousef [this message]
2023-08-21 10:34 ` [PATCH 0/4] Fix dvfs_headroom escaping uclamp constraints Rafael J. Wysocki
2023-08-26 19:17 ` Qais Yousef
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=20230826202711.n73r5wcpibdoiiba@airbuntu \
--to=qyousef@layalina.io \
--cc=dietmar.eggemann@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lukasz.luba@arm.com \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@linaro.org \
/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