From: Peter Zijlstra <peterz@infradead.org>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Juri Lelli <juri.lelli@arm.com>,
mingo@redhat.com, viresh.kumar@linaro.org,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
tglx@linutronix.de, vincent.guittot@linaro.org,
rostedt@goodmis.org, luca.abeni@santannapisa.it,
claudio@evidence.eu.com, tommaso.cucinotta@santannapisa.it,
bristot@redhat.com, mathieu.poirier@linaro.org,
tkjos@android.com, joelaf@google.com, andresoportus@google.com,
morten.rasmussen@arm.com, dietmar.eggemann@arm.com,
patrick.bellasi@arm.com, Ingo Molnar <mingo@kernel.org>
Subject: Re: [PATCH RFC 4/8] sched/cpufreq_schedutil: split utilization signals
Date: Wed, 24 May 2017 09:01:07 +0200 [thread overview]
Message-ID: <20170524070107.xq7tmjxqg6afsrss@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <1941953.5pVr1esCdP@aspire.rjw.lan>
On Wed, May 24, 2017 at 01:30:36AM +0200, Rafael J. Wysocki wrote:
> On Tuesday, May 23, 2017 09:29:27 PM Peter Zijlstra wrote:
> > On Tue, May 23, 2017 at 09:53:47AM +0100, Juri Lelli wrote:
> > > To be able to treat utilization signals of different scheduling classes
> > > in different ways (e.g., CFS signal might be stale while DEADLINE signal
> > > is never stale by design) we need to split sugov_cpu::util signal in two:
> > > util_cfs and util_dl.
> > >
> > > This patch does that by also changing sugov_get_util() parameter list.
> > > After this change aggregation of the different signals has to be performed
> > > by sugov_get_util() users (so that they can decide what to do with the
> > > different signals).
> >
> > So what I don't see this patch doing; and I don't remember if cpufreq is
> > ready for this at all, is set the util_dl as min/guaranteed freq and
> > util_cfs+util_dl as requested freq.
>
> I'm totally unsure what you mean here.
I was thinking of the CPPC/HWP stuff, where you can set different
frequencies with different levels of guarantees.
We'd want to set util_dl as the minimum (guaranteed) performance, and
util_dl + util_cfs as the desired performance level.
> cpufreq doesn't have a "guaranteed frequency" concept of any sort right now.
I was afraid of that ;-) I think we want a comment in the code stating
that this is the desired goal though. Then once cpufreq is ready to deal
with it we can change it..
next prev parent reply other threads:[~2017-05-24 7:01 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-23 8:53 [PATCH RFC 0/8] SCHED_DEADLINE freq/cpu invariance and OPP selection Juri Lelli
2017-05-23 8:53 ` [PATCH RFC 1/8] sched/cpufreq_schedutil: make use of DEADLINE utilization signal Juri Lelli
2017-05-23 8:53 ` [PATCH RFC 2/8] sched/deadline: move cpu frequency selection triggering points Juri Lelli
2017-05-23 8:53 ` [PATCH RFC 3/8] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE Juri Lelli
2017-05-23 18:52 ` Peter Zijlstra
2017-05-24 9:31 ` Juri Lelli
2017-05-23 8:53 ` [PATCH RFC 4/8] sched/cpufreq_schedutil: split utilization signals Juri Lelli
2017-05-23 19:04 ` Peter Zijlstra
2017-05-24 9:01 ` Juri Lelli
2017-05-23 19:29 ` Peter Zijlstra
2017-05-23 23:30 ` Rafael J. Wysocki
2017-05-24 7:01 ` Peter Zijlstra [this message]
2017-05-24 9:01 ` Juri Lelli
2017-05-23 8:53 ` [PATCH RFC 5/8] sched/cpufreq_schedutil: always consider all CPUs when deciding next freq Juri Lelli
2017-05-23 8:53 ` [PATCH RFC 6/8] sched/sched.h: remove sd arch_scale_freq_capacity parameter Juri Lelli
2017-05-23 8:53 ` [PATCH RFC 7/8] sched/sched.h: move arch_scale_{freq,cpu}_capacity outside CONFIG_SMP Juri Lelli
2017-05-23 8:53 ` [PATCH RFC 8/8] sched/deadline: make bandwidth enforcement scale-invariant Juri Lelli
2017-05-23 20:23 ` [PATCH RFC 0/8] SCHED_DEADLINE freq/cpu invariance and OPP selection Peter Zijlstra
2017-05-23 20:29 ` Peter Zijlstra
2017-05-24 9:25 ` Juri Lelli
2017-05-24 9:41 ` Peter Zijlstra
2017-05-24 9:50 ` Juri Lelli
2017-05-24 11:31 ` Peter Zijlstra
2017-05-24 10:01 ` Luca Abeni
2017-05-24 11:29 ` Peter Zijlstra
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=20170524070107.xq7tmjxqg6afsrss@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=andresoportus@google.com \
--cc=bristot@redhat.com \
--cc=claudio@evidence.eu.com \
--cc=dietmar.eggemann@arm.com \
--cc=joelaf@google.com \
--cc=juri.lelli@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=luca.abeni@santannapisa.it \
--cc=mathieu.poirier@linaro.org \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=morten.rasmussen@arm.com \
--cc=patrick.bellasi@arm.com \
--cc=rjw@rjwysocki.net \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=tkjos@android.com \
--cc=tommaso.cucinotta@santannapisa.it \
--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;
as well as URLs for NNTP newsgroup(s).