From: Peter Zijlstra <peterz@infradead.org>
To: Juri Lelli <juri.lelli@arm.com>
Cc: mingo@redhat.com, rjw@rjwysocki.net, 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
Subject: Re: [PATCH RFC 0/8] SCHED_DEADLINE freq/cpu invariance and OPP selection
Date: Tue, 23 May 2017 22:23:21 +0200 [thread overview]
Message-ID: <20170523202321.3bygt6ydyiy5xief@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20170523085351.18586-1-juri.lelli@arm.com>
On Tue, May 23, 2017 at 09:53:43AM +0100, Juri Lelli wrote:
> A point that is still very much up for discussion (more that the others :) is
> how we implement frequency/cpu scaling. SCHED_FLAG_RECLAIM tasks only need
> grub_reclaim(), as the function already scales their reservation runtime
> considering other reservations and maximum bandwidth a CPU has to offer.
> However, for normal !RECLAIM tasks multiple things can be implemented which
> seem to make sense:
>
> - don't scale at all: normal tasks will only get a % of CPU _time_ as granted
> by AC
> - go to max as soon as a normal task in enqueued: this because dimensioning of
> parameters is usually done at max OPP/biggest CPU and normal task assume
> that this is always the condition when they run
> - scale runtime acconding to current frequency and max CPU capacity: this is
> what this set is currently implementing
>
> Opinions?
So I'm terribly confused...
By using the active bandwidth to select frequency we effectively
reduce idle time (to 0 if we had infinite granular frequency steps and
no margins).
So !RECLAIM works as expected. They get the time they reserved, since
that was taken into account by active bandwidth.
And RECLAIM works, since that only promises to (re)distribute idle time,
and if there is none that is an easy task.
Where is the problem?
next prev parent reply other threads:[~2017-05-23 21:58 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
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 ` Peter Zijlstra [this message]
2017-05-23 20:29 ` [PATCH RFC 0/8] SCHED_DEADLINE freq/cpu invariance and OPP selection 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=20170523202321.3bygt6ydyiy5xief@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@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).