mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Juri Lelli <juri.lelli@arm.com>
To: peterz@infradead.org, mingo@redhat.com, rjw@rjwysocki.net,
	viresh.kumar@linaro.org
Cc: 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, juri.lelli@arm.com
Subject: [RFD PATCH 0/5] SCHED_DEADLINE freq/cpu invariance and OPP selection
Date: Fri, 24 Mar 2017 14:08:55 +0000	[thread overview]
Message-ID: <20170324140900.7334-1-juri.lelli@arm.com> (raw)

Hi,

this is a very exploratory set implementing frequency/cpu invariance and OPP
selection for SCHED_DEADLINE. The set has been slightly tested on a Juno
platform. While the actual implementation is very premature, I'm posting this
early to facilitate discussion at OSPM-summit [1].

Results of the testing, highlighting why these features are useful are
available here:

 - without the set
   https://gist.github.com/a6e3ee99cec32e00cc537b53cd3d54d2

 - with the set
   https://gist.github.com/1f7d485fc3ce9234fe627dcb53b2935c

The set is based on tip/sched/core as of today (bc4278987e38) plus a couple of
schedutil fixes coming from linux-pm/linux-next and Luca's "CPU reclaiming for
SCHED_DEADLINE" v5 [2].

Patches high level description:

 o [01-02]/05 add the necessary links to start accounting DEADLINE contribution
              to OPP selection 
 o 03/05      it's an hack to make possible (on ARM) to change frequency for
              DEADLINE tasks (that would possibly delay the SCHED_FIFO worker
              kthread); suggestions on how to do this properly are very welcome
 o 04/05      it's a schedutil change that copes with the fact that DEADLINE
              doesn't require periodic OPP selection triggering point
 o 05/05      implements frequency/cpu invariance for tasks' reservation
              parameters*; which basically means that we implement GRUB-PA [3]

Please have a look. Feedback on how we want to shape this is the sole purpose
of this posting.

In case you would like to test this out:

 git://linux-arm.org/linux-jl.git upstream/deadline/freq-rfd

Best,

- Juri

[1] http://retis.sssup.it/ospm-summit/index.html
[2] https://marc.info/?l=linux-kernel&m=149029880524038
[3] C. Scordino, G. Lipari, A Resource Reservation Algorithm for Power-Aware
    Scheduling of Periodic and Aperiodic Real-Time Tasks, IEEE Transactions
    on Computers, December 2006.

* Notice that this currently breaks !CONFIG_SMP, as arch_scale_{freq,cpu}
_capacity and SCHED_CAPACITY_SCALE are only defined on CONFIG_SMP. Fixing
this particular issue is straightforward, but we should probably look into
making frequency scaling (and PELT averages) available on !CONFIG_SMP as well
(so that schedutil can work on such configurations for example). Since this is
only an RFD and since a proper rework might be non trivial, I decided to leave
it out of scope for the time being.

Juri Lelli (5):
  sched/cpufreq_schedutil: make use of DEADLINE utilization signal
  sched/deadline: move cpu frequency selection triggering points
  sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE
  sched/cpufreq_schedutil: always consider all CPUs when deciding next
    freq
  sched/deadline: make bandwidth enforcement scale-invariant

 include/linux/sched.h            |  1 +
 include/linux/sched/cpufreq.h    |  2 --
 include/uapi/linux/sched.h       |  1 +
 kernel/sched/core.c              | 19 +++++++++++++++++--
 kernel/sched/cpufreq_schedutil.c | 37 ++++++++++++++++++++++---------------
 kernel/sched/deadline.c          | 40 +++++++++++++++++++++++++++++++++-------
 kernel/sched/fair.c              |  2 --
 kernel/sched/sched.h             | 10 +++++++++-
 8 files changed, 83 insertions(+), 29 deletions(-)

-- 
2.10.0

             reply	other threads:[~2017-03-24 14:09 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-24 14:08 Juri Lelli [this message]
2017-03-24 14:08 ` [RFD PATCH 1/5] sched/cpufreq_schedutil: make use of DEADLINE utilization signal Juri Lelli
2017-03-24 14:08 ` [RFD PATCH 2/5] sched/deadline: move cpu frequency selection triggering points Juri Lelli
2017-03-24 14:08 ` [RFD PATCH 3/5] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE Juri Lelli
2017-03-27 16:50   ` Peter Zijlstra
2017-03-27 17:01     ` Juri Lelli
2017-03-27 17:05       ` Rafael J. Wysocki
2017-03-27 17:13         ` Juri Lelli
2017-03-27 17:37           ` Rafael J. Wysocki
2017-03-27 18:09             ` Mark Brown
2017-03-30 15:50             ` Vikram Mulukutla
2017-03-30 20:22               ` Rafael J. Wysocki
2017-03-31  7:26                 ` Juri Lelli
2017-03-27 18:05     ` Mark Brown
2017-03-28  9:29     ` Vincent Guittot
2017-03-28 10:20       ` Peter Zijlstra
2017-03-24 14:08 ` [RFD PATCH 4/5] sched/cpufreq_schedutil: always consider all CPUs when deciding next freq Juri Lelli
2017-03-29 22:41   ` Rafael J. Wysocki
2017-03-30  8:58     ` Juri Lelli
2017-03-30 13:21       ` Vincent Guittot
2017-03-30 20:13       ` Rafael J. Wysocki
2017-03-31  7:31         ` Juri Lelli
2017-03-31  9:03           ` Rafael J. Wysocki
2017-03-31  9:16             ` Juri Lelli
2017-03-24 14:09 ` [RFD PATCH 5/5] sched/deadline: make bandwidth enforcement scale-invariant Juri Lelli

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=20170324140900.7334-1-juri.lelli@arm.com \
    --to=juri.lelli@arm.com \
    --cc=andresoportus@google.com \
    --cc=bristot@redhat.com \
    --cc=claudio@evidence.eu.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=joelaf@google.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=peterz@infradead.org \
    --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

all inboxes | Powered by JetHome®