Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1356939 > unrolled thread

[PATCH 0/8] schedutil enhancements

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/8] schedutil enhancements Michael Turquette <mturquette@baylibre.com> - 2016-03-14 06:30 +0100
    [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable Michael Turquette <mturquette@baylibre.com> - 2016-03-14 06:30 +0100
      Re: [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable Peter Zijlstra <peterz@infradead.org> - 2016-03-15 22:30 +0100
        Re: [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable Peter Zijlstra <peterz@infradead.org> - 2016-03-15 22:50 +0100
          Re: [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable Steve Muckle <steve.muckle@linaro.org> - 2016-03-16 04:40 +0100
            Re: [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable Peter Zijlstra <peterz@infradead.org> - 2016-03-16 09:10 +0100
              Re: [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable Juri Lelli <Juri.Lelli@arm.com> - 2016-03-16 11:10 +0100
                Re: [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable Steve Muckle <steve.muckle@linaro.org> - 2016-03-16 19:00 +0100
                  Re: [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable Michael Turquette <mturquette@baylibre.com> - 2016-03-16 23:10 +0100
                  Re: [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable Juri Lelli <Juri.Lelli@arm.com> - 2016-03-17 10:40 +0100
                    Re: [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable Steve Muckle <steve.muckle@linaro.org> - 2016-03-17 15:00 +0100
                      Re: [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable Patrick Bellasi <patrick.bellasi@arm.com> - 2016-03-17 17:00 +0100
              Re: [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-16 13:50 +0100
            Re: [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable Michael Turquette <mturquette@baylibre.com> - 2016-03-16 23:10 +0100
    [PATCH 1/8] sched/cpufreq: remove cpufreq_trigger_update() Michael Turquette <mturquette@baylibre.com> - 2016-03-14 06:30 +0100
      Re: [PATCH 1/8] sched/cpufreq: remove cpufreq_trigger_update() Peter Zijlstra <peterz@infradead.org> - 2016-03-15 22:20 +0100
        Re: [PATCH 1/8] sched/cpufreq: remove cpufreq_trigger_update() Peter Zijlstra <peterz@infradead.org> - 2016-03-15 23:00 +0100
      Re: [PATCH 1/8] sched/cpufreq: remove cpufreq_trigger_update() Peter Zijlstra <peterz@infradead.org> - 2016-03-16 09:10 +0100
    [PATCH 5/8] sched/cpufreq: pass sched class into cpufreq_update_util Michael Turquette <mturquette@baylibre.com> - 2016-03-14 06:30 +0100
      Re: [PATCH 5/8] sched/cpufreq: pass sched class into  cpufreq_update_util Peter Zijlstra <peterz@infradead.org> - 2016-03-15 22:30 +0100
        Re: [PATCH 5/8] sched/cpufreq: pass sched class into  cpufreq_update_util Steve Muckle <steve.muckle@linaro.org> - 2016-03-16 05:00 +0100
        Re: [PATCH 5/8] sched/cpufreq: pass sched class into  cpufreq_update_util Peter Zijlstra <peterz@infradead.org> - 2016-03-16 08:50 +0100
          Re: [PATCH 5/8] sched/cpufreq: pass sched class into cpufreq_update_util Vincent Guittot <vincent.guittot@linaro.org> - 2016-03-16 09:40 +0100
            Re: [PATCH 5/8] sched/cpufreq: pass sched class into  cpufreq_update_util Peter Zijlstra <peterz@infradead.org> - 2016-03-16 10:00 +0100
              Re: [PATCH 5/8] sched/cpufreq: pass sched class into cpufreq_update_util Vincent Guittot <vincent.guittot@linaro.org> - 2016-03-16 10:20 +0100
              Re: [PATCH 5/8] sched/cpufreq: pass sched class into cpufreq_update_util "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-16 13:40 +0100
                Re: [PATCH 5/8] sched/cpufreq: pass sched class into  cpufreq_update_util Peter Zijlstra <peterz@infradead.org> - 2016-03-16 14:20 +0100
                  Re: [PATCH 5/8] sched/cpufreq: pass sched class into cpufreq_update_util "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-16 14:30 +0100
                    Re: [PATCH 5/8] sched/cpufreq: pass sched class into  cpufreq_update_util Peter Zijlstra <peterz@infradead.org> - 2016-03-16 14:50 +0100
    [PATCH 8/8] sched: prefer cpufreq_scale_freq_capacity Michael Turquette <mturquette@baylibre.com> - 2016-03-14 06:30 +0100
      Re: [PATCH 8/8] sched: prefer cpufreq_scale_freq_capacity Dietmar Eggemann <dietmar.eggemann@arm.com> - 2016-03-15 20:20 +0100
        Re: [PATCH 8/8] sched: prefer cpufreq_scale_freq_capacity Michael Turquette <mturquette@baylibre.com> - 2016-03-15 21:50 +0100
          Re: [PATCH 8/8] sched: prefer cpufreq_scale_freq_capacity Dietmar Eggemann <dietmar.eggemann@arm.com> - 2016-03-16 20:50 +0100
            Re: [PATCH 8/8] sched: prefer cpufreq_scale_freq_capacity Peter Zijlstra <peterz@infradead.org> - 2016-03-16 21:10 +0100
              Re: [PATCH 8/8] sched: prefer cpufreq_scale_freq_capacity "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-16 22:40 +0100
      Re: [PATCH 8/8] sched: prefer cpufreq_scale_freq_capacity Peter Zijlstra <peterz@infradead.org> - 2016-03-15 22:50 +0100
        Re: [PATCH 8/8] sched: prefer cpufreq_scale_freq_capacity Peter Zijlstra <peterz@infradead.org> - 2016-03-16 08:50 +0100
          Re: [PATCH 8/8] sched: prefer cpufreq_scale_freq_capacity Peter Zijlstra <peterz@infradead.org> - 2016-03-16 13:50 +0100
    [PATCH 2/8] sched/fair: add margin to utilization update Michael Turquette <mturquette@baylibre.com> - 2016-03-14 06:30 +0100
      Re: [PATCH 2/8] sched/fair: add margin to utilization update Peter Zijlstra <peterz@infradead.org> - 2016-03-15 22:20 +0100
        Re: [PATCH 2/8] sched/fair: add margin to utilization update Peter Zijlstra <peterz@infradead.org> - 2016-03-15 22:50 +0100
      Re: [PATCH 2/8] sched/fair: add margin to utilization update Steve Muckle <steve.muckle@linaro.org> - 2016-03-16 04:00 +0100
        Re: [PATCH 2/8] sched/fair: add margin to utilization update Michael Turquette <mturquette@baylibre.com> - 2016-03-16 23:20 +0100
    [PATCH 3/8] sched/cpufreq: new cfs capacity margin helpers Michael Turquette <mturquette@baylibre.com> - 2016-03-14 06:30 +0100
      Re: [PATCH 3/8] sched/cpufreq: new cfs capacity margin helpers Peter Zijlstra <peterz@infradead.org> - 2016-03-15 22:20 +0100
    Re: [PATCH 0/8] schedutil enhancements "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-16 01:10 +0100

Page 1 of 3  [1] 2 3  Next page →

#1356939 — [PATCH 0/8] schedutil enhancements

I'm happy that scheduler-driven cpu frequency selection is getting some
attention. Rafael's recent schedutil governor is a step in the right direction.
This series builds on top of Rafael's schedutil governor, bringing it to parity
with some of the features in the schedfreq series posted by Steve[0], as well
as adding a couple of new things.

Patch 1 removes cpufreq_trigger_update()

Patches 2-4 move the cfs capacity margin out of the governor and into
cfs. This value is made tunable by a sysfs control in schedutil.

Patches 5-6 make cpufreq_update_util() aware of multiple scheduler
classes (cfs, rt & dl), and add storage & summation of these per-class
utilization values into schedutil.

Patches 7-8 introduces Dietmar's generic cpufreq implementation[1] of the
frequency invariance hook and changes the preprocessor magic in sched.h to
favor the cpufreq implementation over arch- or platform-specific ones.

If accepted, this series makes it trivial to port Steve and Juri's fine-grained
frequency selection in cfs and Vincent's rt utilization patch to the schedutil
governor.[2-6]

[0] lkml.kernel.org/r/1456190570-4475-1-git-send-email-smuckle@linaro.org
[1] https://git.linaro.org/people/steve.muckle/kernel.git/commit/1b7e57f89f14f7600e75e6fde42bf22d72927b3d
[2] lkml.kernel.org/r/1456190570-4475-5-git-send-email-smuckle@linaro.org
[3] lkml.kernel.org/r/1456190570-4475-6-git-send-email-smuckle@linaro.org
[4] lkml.kernel.org/r/1456190570-4475-7-git-send-email-smuckle@linaro.org
[5] lkml.kernel.org/r/1456190570-4475-8-git-send-email-smuckle@linaro.org
[6] lkml.kernel.org/r/1456190570-4475-11-git-send-email-smuckle@linaro.org

Dietmar Eggemann (1):
  cpufreq: Frequency invariant scheduler load-tracking support

Michael Turquette (7):
  sched/cpufreq: remove cpufreq_trigger_update()
  sched/fair: add margin to utilization update
  sched/cpufreq: new cfs capacity margin helpers
  cpufreq/schedutil: sysfs capacity margin tunable
  sched/cpufreq: pass sched class into cpufreq_update_util
  cpufreq/schedutil: sum per-sched class utilization
  sched: prefer cpufreq_scale_freq_capacity

 drivers/cpufreq/cpufreq.c           | 29 ++++++++++++
 drivers/cpufreq/cpufreq_governor.c  |  5 +-
 drivers/cpufreq/cpufreq_schedutil.c | 70 ++++++++++++++++++++++++----
 drivers/cpufreq/intel_pstate.c      |  5 +-
 include/linux/cpufreq.h             |  3 ++
 include/linux/sched.h               | 19 ++++++--
 kernel/sched/cpufreq.c              | 92 +++++++++++++++++++++++++------------
 kernel/sched/deadline.c             |  2 +-
 kernel/sched/fair.c                 | 18 +++++++-
 kernel/sched/rt.c                   |  2 +-
 kernel/sched/sched.h                | 29 +++++++++---
 11 files changed, 219 insertions(+), 55 deletions(-)

-- 
2.1.4

[toc] | [next] | [standalone]

#1356941 — [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable

With the addition of the global cfs capacity margin helpers in patch,
"sched/cpufreq: new cfs capacity margin helpers", we can now export
sysfs tunables from the schedutil governor. This allows privileged users
to tune the value more easily.

The margin value is global to cfs, not per-policy. As such schedutil
does not store any state about the margin. Schedutil restores the margin
value to its default value when exiting.

Signed-off-by: Michael Turquette <mturquette+renesas@baylibre.com>
---
 drivers/cpufreq/cpufreq_schedutil.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/drivers/cpufreq/cpufreq_schedutil.c b/drivers/cpufreq/cpufreq_schedutil.c
index 5aa26bf..12e49b9 100644
--- a/drivers/cpufreq/cpufreq_schedutil.c
+++ b/drivers/cpufreq/cpufreq_schedutil.c
@@ -246,8 +246,32 @@ static ssize_t rate_limit_us_store(struct gov_attr_set *attr_set, const char *bu
 
 static struct governor_attr rate_limit_us = __ATTR_RW(rate_limit_us);
 
+static ssize_t capacity_margin_show(struct gov_attr_set *not_used,
+					   char *buf)
+{
+	return sprintf(buf, "%lu\n", cpufreq_get_cfs_capacity_margin());
+}
+
+static ssize_t capacity_margin_store(struct gov_attr_set *attr_set,
+				  const char *buf, size_t count)
+{
+	unsigned long margin;
+	int ret;
+
+	ret = sscanf(buf, "%lu", &margin);
+	if (ret != 1)
+		return -EINVAL;
+
+	cpufreq_set_cfs_capacity_margin(margin);
+
+	return count;
+}
+
+static struct governor_attr capacity_margin = __ATTR_RW(capacity_margin);
+
 static struct attribute *sugov_attributes[] = {
 	&rate_limit_us.attr,
+	&capacity_margin.attr,
 	NULL
 };
 
@@ -381,6 +405,7 @@ static int sugov_exit(struct cpufreq_policy *policy)
 
 	mutex_lock(&global_tunables_lock);
 
+	cpufreq_reset_cfs_capacity_margin();
 	count = gov_attr_set_put(&tunables->attr_set, &sg_policy->tunables_hook);
 	policy->governor_data = NULL;
 	if (!count)
-- 
2.1.4

[toc] | [prev] | [next] | [standalone]

#1358253 — Re: [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable

On Sun, Mar 13, 2016 at 10:22:08PM -0700, Michael Turquette wrote:
> With the addition of the global cfs capacity margin helpers in patch,
> "sched/cpufreq: new cfs capacity margin helpers", we can now export
> sysfs tunables from the schedutil governor. This allows privileged users
> to tune the value more easily.
> 
> The margin value is global to cfs, not per-policy. As such schedutil
> does not store any state about the margin. Schedutil restores the margin
> value to its default value when exiting.

Yuck sysfs.. I would really rather we did not expose this per default.
And certainly not in this weird form.

[toc] | [prev] | [next] | [standalone]

#1358277 — Re: [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable

On Tue, Mar 15, 2016 at 02:40:43PM -0700, Michael Turquette wrote:
> Quoting Peter Zijlstra (2016-03-15 14:20:47)
> > On Sun, Mar 13, 2016 at 10:22:08PM -0700, Michael Turquette wrote:
> > > With the addition of the global cfs capacity margin helpers in patch,
> > > "sched/cpufreq: new cfs capacity margin helpers", we can now export
> > > sysfs tunables from the schedutil governor. This allows privileged users
> > > to tune the value more easily.
> > > 
> > > The margin value is global to cfs, not per-policy. As such schedutil
> > > does not store any state about the margin. Schedutil restores the margin
> > > value to its default value when exiting.
> > 
> > Yuck sysfs.. I would really rather we did not expose this per default.
> > And certainly not in this weird form.
> 
> I'm happy to change capacity_margin to up_threshold and use a
> percentage.
> 
> The sysfs approach has two benefits. First, it is aligned with cpufreq
> user expectations. Second, there has been rough consensus that this
> value should be tunable and sysfs gets us there quickly and painlessly.
> We're already exporting rate_limit_us for schedutil via sysfs. Is there
> a better way interface you can recommend?

It really depends on how tunable you want this to be. Do we always want
this to be a tunable, or just now while we're playing about with the
whole thing?

The problem with exposing it in sysfs is that you cannot take it out
again, it becomes ABI.

What we do for all the scheduler tunables (pretty much every time we
have to take a value out of thin air), is we make them const for
!SCHED_DEBUG builds, but have them as sysctl for SCHED_DEBUG builds
(although we should probably move them to /debug/sched/ or somesuch).

That way you get better code generation (compile time constants rule)
for !debug builds, while having the 'joy' of poking at your number on
debug builds.

[toc] | [prev] | [next] | [standalone]

#1358508 — Re: [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable

On 03/15/2016 03:37 PM, Michael Turquette wrote:
>>>> Yuck sysfs.. I would really rather we did not expose this per default.
>>>> > > > And certainly not in this weird form.
>>> > > 
>>> > > I'm happy to change capacity_margin to up_threshold and use a
>>> > > percentage.
>>> > > 
>>> > > The sysfs approach has two benefits. First, it is aligned with cpufreq
>>> > > user expectations. Second, there has been rough consensus that this
>>> > > value should be tunable and sysfs gets us there quickly and painlessly.
>>> > > We're already exporting rate_limit_us for schedutil via sysfs. Is there
>>> > > a better way interface you can recommend?
>> > 
>> > It really depends on how tunable you want this to be. Do we always want
>> > this to be a tunable, or just now while we're playing about with the
>> > whole thing?
>
> I had considered this myself, and I really think that Steve and Juri
> should chime in as they have spent more time tuning and running the
> numbers.
> 
> I'm inclined to think that a debug version would be good enough, as I
> don't imagine this value being changed at run-time by some userspace
> daemon or something.
> 
> Then again, maybe this knob will be part of the mythical
> power-vs-performance slider?

Patrick Bellasi's schedtune series [0] (which I think is the referenced
mythical slider) aims to provide a more sophisticated interface for
tuning scheduler-driven frequency selection. In addition to a global
boost value it includes a cgroup controller as well for per-task tuning.

I would definitely expect the margin/boost value to be modified at
runtime, for example if the battery is running low, or the user wants
100% performance for a while, or the userspace framework wants to
temporarily tailor the performance level for a particular set of tasks, etc.

[0] http://article.gmane.org/gmane.linux.kernel/2022959

[toc] | [prev] | [next] | [standalone]

#1358612 — Re: [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable

On Tue, Mar 15, 2016 at 08:36:57PM -0700, Steve Muckle wrote:
> > Then again, maybe this knob will be part of the mythical
> > power-vs-performance slider?
> 
> Patrick Bellasi's schedtune series [0] (which I think is the referenced
> mythical slider) aims to provide a more sophisticated interface for
> tuning scheduler-driven frequency selection. In addition to a global
> boost value it includes a cgroup controller as well for per-task tuning.
> 
> I would definitely expect the margin/boost value to be modified at
> runtime, for example if the battery is running low, or the user wants
> 100% performance for a while, or the userspace framework wants to
> temporarily tailor the performance level for a particular set of tasks, etc.

OK, so how about we start with it as a debug knob, and once we have
experience and feel like it is indeed a useful runtime knob, we upgrade
it to ABI.

The problem with starting out as ABI is that its hard to take away
again.

[toc] | [prev] | [next] | [standalone]

#1358782 — Re: [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable

Hi,

On 16/03/16 09:05, Peter Zijlstra wrote:
> On Tue, Mar 15, 2016 at 08:36:57PM -0700, Steve Muckle wrote:
> > > Then again, maybe this knob will be part of the mythical
> > > power-vs-performance slider?
> > 
> > Patrick Bellasi's schedtune series [0] (which I think is the referenced
> > mythical slider) aims to provide a more sophisticated interface for
> > tuning scheduler-driven frequency selection. In addition to a global
> > boost value it includes a cgroup controller as well for per-task tuning.
> > 
> > I would definitely expect the margin/boost value to be modified at
> > runtime, for example if the battery is running low, or the user wants
> > 100% performance for a while, or the userspace framework wants to
> > temporarily tailor the performance level for a particular set of tasks, etc.
> 
> OK, so how about we start with it as a debug knob, and once we have
> experience and feel like it is indeed a useful runtime knob, we upgrade
> it to ABI.
> 

I tend to agree here. To me the margin is something that we need to make
this thing work and to get acceptable performance out of the box. So we
can play with it while debugging, but I consider the schedtune slider as
the way to tune the system at runtime.

Best,

- Juri

[toc] | [prev] | [next] | [standalone]

#1359208 — Re: [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable

On 03/16/2016 03:02 AM, Juri Lelli wrote:
> Hi,
> 
> On 16/03/16 09:05, Peter Zijlstra wrote:
>> On Tue, Mar 15, 2016 at 08:36:57PM -0700, Steve Muckle wrote:
>>>> Then again, maybe this knob will be part of the mythical
>>>> power-vs-performance slider?
>>>
>>> Patrick Bellasi's schedtune series [0] (which I think is the referenced
>>> mythical slider) aims to provide a more sophisticated interface for
>>> tuning scheduler-driven frequency selection. In addition to a global
>>> boost value it includes a cgroup controller as well for per-task tuning.
>>>
>>> I would definitely expect the margin/boost value to be modified at
>>> runtime, for example if the battery is running low, or the user wants
>>> 100% performance for a while, or the userspace framework wants to
>>> temporarily tailor the performance level for a particular set of tasks, etc.
>>
>> OK, so how about we start with it as a debug knob, and once we have
>> experience and feel like it is indeed a useful runtime knob, we upgrade
>> it to ABI.
>>
> 
> I tend to agree here. To me the margin is something that we need to make
> this thing work and to get acceptable performance out of the box. So we
> can play with it while debugging, but I consider the schedtune slider as
> the way to tune the system at runtime.

Could the default schedtune value not serve as the out of the box margin?

Regardless I agree that a debug interface is the way to go for now while
we figure things out.

[toc] | [prev] | [next] | [standalone]

#1359386 — Re: [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable

Quoting Steve Muckle (2016-03-16 10:55:49)
> On 03/16/2016 03:02 AM, Juri Lelli wrote:
> > Hi,
> > 
> > On 16/03/16 09:05, Peter Zijlstra wrote:
> >> On Tue, Mar 15, 2016 at 08:36:57PM -0700, Steve Muckle wrote:
> >>>> Then again, maybe this knob will be part of the mythical
> >>>> power-vs-performance slider?
> >>>
> >>> Patrick Bellasi's schedtune series [0] (which I think is the referenced
> >>> mythical slider) aims to provide a more sophisticated interface for
> >>> tuning scheduler-driven frequency selection. In addition to a global
> >>> boost value it includes a cgroup controller as well for per-task tuning.
> >>>
> >>> I would definitely expect the margin/boost value to be modified at
> >>> runtime, for example if the battery is running low, or the user wants
> >>> 100% performance for a while, or the userspace framework wants to
> >>> temporarily tailor the performance level for a particular set of tasks, etc.
> >>
> >> OK, so how about we start with it as a debug knob, and once we have
> >> experience and feel like it is indeed a useful runtime knob, we upgrade
> >> it to ABI.
> >>
> > 
> > I tend to agree here. To me the margin is something that we need to make
> > this thing work and to get acceptable performance out of the box. So we
> > can play with it while debugging, but I consider the schedtune slider as
> > the way to tune the system at runtime.
> 
> Could the default schedtune value not serve as the out of the box margin?

It can. Let's keep the kernel interfaces in patch #2 for changing the
margin/threshold, and schedtune can call these interfaces.

Regards,
Mike

> 
> Regardless I agree that a debug interface is the way to go for now while
> we figure things out.
> 

[toc] | [prev] | [next] | [standalone]

#1359666 — Re: [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable

On 16/03/16 10:55, Steve Muckle wrote:
> On 03/16/2016 03:02 AM, Juri Lelli wrote:
> > Hi,
> > 
> > On 16/03/16 09:05, Peter Zijlstra wrote:
> >> On Tue, Mar 15, 2016 at 08:36:57PM -0700, Steve Muckle wrote:
> >>>> Then again, maybe this knob will be part of the mythical
> >>>> power-vs-performance slider?
> >>>
> >>> Patrick Bellasi's schedtune series [0] (which I think is the referenced
> >>> mythical slider) aims to provide a more sophisticated interface for
> >>> tuning scheduler-driven frequency selection. In addition to a global
> >>> boost value it includes a cgroup controller as well for per-task tuning.
> >>>
> >>> I would definitely expect the margin/boost value to be modified at
> >>> runtime, for example if the battery is running low, or the user wants
> >>> 100% performance for a while, or the userspace framework wants to
> >>> temporarily tailor the performance level for a particular set of tasks, etc.
> >>
> >> OK, so how about we start with it as a debug knob, and once we have
> >> experience and feel like it is indeed a useful runtime knob, we upgrade
> >> it to ABI.
> >>
> > 
> > I tend to agree here. To me the margin is something that we need to make
> > this thing work and to get acceptable performance out of the box. So we
> > can play with it while debugging, but I consider the schedtune slider as
> > the way to tune the system at runtime.
> 
> Could the default schedtune value not serve as the out of the box margin?
> 

I'm not sure I understand you here. For me schedtune should be disabled
by default, so I'd say that it doesn't introduce any additional margin
by default. But we still need a margin to make the governor work without
schedtune in the mix.

> Regardless I agree that a debug interface is the way to go for now while
> we figure things out.
> 

Looks good to me.

Best,

- Juri

[toc] | [prev] | [next] | [standalone]

#1359870 — Re: [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable

On 03/17/2016 02:40 AM, Juri Lelli wrote:
>> Could the default schedtune value not serve as the out of the box margin?
>>
> I'm not sure I understand you here. For me schedtune should be disabled
> by default, so I'd say that it doesn't introduce any additional margin
> by default. But we still need a margin to make the governor work without
> schedtune in the mix.

Why not have schedtune be enabled always, and use it to add the margin?
It seems like it'd simplify things.

I haven't looked at the schedtune code at all so I don't know whether
this makes sense given its current implementation. But conceptually I
don't know why we'd need or want one margin in schedutil which will be
tunable, and then another mechanism for tuning as well.

[toc] | [prev] | [next] | [standalone]

#1359973 — Re: [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable

On 17-Mar 06:55, Steve Muckle wrote:
> On 03/17/2016 02:40 AM, Juri Lelli wrote:
> >> Could the default schedtune value not serve as the out of the box margin?
> >>
> > I'm not sure I understand you here. For me schedtune should be disabled
> > by default, so I'd say that it doesn't introduce any additional margin
> > by default. But we still need a margin to make the governor work without
> > schedtune in the mix.
> 
> Why not have schedtune be enabled always, and use it to add the margin?
> It seems like it'd simplify things.

Actually one of the effects we noticed when SchedTune and SchedFreq
are both in use is that we have a sort of "double boosting" effect.

SchedTune boosts the CPU utilization signal, thus already providing a
sort of margin for the selection of the OPP. This margin overlaps with
the SchedFreq margin, which in turns could results in the selection of
an OPP even more higher than required (with boost already accouned).
 
> I haven't looked at the schedtune code at all so I don't know whether
> this makes sense given its current implementation.

The current implementation requires review, of course ;-)
Last (and only) posting is based on top of SchedFreq code, as it was
at that time.

> But conceptually I don't know why we'd need or want one margin in
> schedutil which will be tunable, and then another mechanism for
> tuning as well.

I agree with Steve on the conceptual standpoint. The main goal of
SchedTune is actually to provide a "single tunable" to bias many
different subsystem in a "consistent" way. Thus, from a conceptual
standpoint, IMO it makes sens to investigate better how the boost value
can be linked with SchedFreq.

A possible option can be to:
1. use an hardcoded margin (M) defined by SchedFreq
   this margin is used to trigger OPP jumps
   when SchedTune _is not_ in use
2. "compose" the M margin with a boost value defined margin (B)
   when SchedTune _is_ in use

This means, e.g.
  schedfreq_margin = max(M, B)
Thus:
a) non boosted tasks (and in general when SchedTune is not in use)
   gets OPPs jumps based on the hardcoded M margin
b) boosted tasks can get more aggressive OPPs jumps based on the B
   margin

While the M margin is hardcoded, the B one is defined via CGroups
depending on the how much tasks needs to be boosted.

-- 
#include <best/regards.h>

Patrick Bellasi

[toc] | [prev] | [next] | [standalone]

#1358956 — Re: [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable

On Wed, Mar 16, 2016 at 9:05 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Tue, Mar 15, 2016 at 08:36:57PM -0700, Steve Muckle wrote:
>> > Then again, maybe this knob will be part of the mythical
>> > power-vs-performance slider?
>>
>> Patrick Bellasi's schedtune series [0] (which I think is the referenced
>> mythical slider) aims to provide a more sophisticated interface for
>> tuning scheduler-driven frequency selection. In addition to a global
>> boost value it includes a cgroup controller as well for per-task tuning.
>>
>> I would definitely expect the margin/boost value to be modified at
>> runtime, for example if the battery is running low, or the user wants
>> 100% performance for a while, or the userspace framework wants to
>> temporarily tailor the performance level for a particular set of tasks, etc.
>
> OK, so how about we start with it as a debug knob, and once we have
> experience and feel like it is indeed a useful runtime knob, we upgrade
> it to ABI.
>
> The problem with starting out as ABI is that its hard to take away
> again.

Agreed, plus it is quite hard to get ABI right from the outset.  Even
if we decide on a sysfs knob, it still is unclear what exactly should
be represented by it in what units etc.

[toc] | [prev] | [next] | [standalone]

#1359390 — Re: [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable

Quoting Steve Muckle (2016-03-15 20:36:57)
> On 03/15/2016 03:37 PM, Michael Turquette wrote:
> >>>> Yuck sysfs.. I would really rather we did not expose this per default.
> >>>> > > > And certainly not in this weird form.
> >>> > > 
> >>> > > I'm happy to change capacity_margin to up_threshold and use a
> >>> > > percentage.
> >>> > > 
> >>> > > The sysfs approach has two benefits. First, it is aligned with cpufreq
> >>> > > user expectations. Second, there has been rough consensus that this
> >>> > > value should be tunable and sysfs gets us there quickly and painlessly.
> >>> > > We're already exporting rate_limit_us for schedutil via sysfs. Is there
> >>> > > a better way interface you can recommend?
> >> > 
> >> > It really depends on how tunable you want this to be. Do we always want
> >> > this to be a tunable, or just now while we're playing about with the
> >> > whole thing?
> >
> > I had considered this myself, and I really think that Steve and Juri
> > should chime in as they have spent more time tuning and running the
> > numbers.
> > 
> > I'm inclined to think that a debug version would be good enough, as I
> > don't imagine this value being changed at run-time by some userspace
> > daemon or something.
> > 
> > Then again, maybe this knob will be part of the mythical
> > power-vs-performance slider?
> 
> Patrick Bellasi's schedtune series [0] (which I think is the referenced
> mythical slider) aims to provide a more sophisticated interface for
> tuning scheduler-driven frequency selection. In addition to a global
> boost value it includes a cgroup controller as well for per-task tuning.

/me spends 15 seconds looking schedtune

> 
> I would definitely expect the margin/boost value to be modified at
> runtime, for example if the battery is running low, or the user wants
> 100% performance for a while, or the userspace framework wants to
> temporarily tailor the performance level for a particular set of tasks, etc.

Right, and it looks like schedtune is a kernel solution, not userspace
solution. The following three interfaces from patch #2 could be used by
schedtune:

unsigned long cpufreq_get_cfs_capacity_margin(void);
void cpufreq_set_cfs_capacity_margin(unsigned long margin);
void cpufreq_reset_cfs_capacity_margin(void);

Then we can let schedtune worry about the userspace abi.

So I'll keep the basic idea of this patch, but explore making it
debuggy, instead of sysfsy.

Regards,
Mike

> 
> [0] http://article.gmane.org/gmane.linux.kernel/2022959

[toc] | [prev] | [next] | [standalone]

#1356943 — [PATCH 1/8] sched/cpufreq: remove cpufreq_trigger_update()

cpufreq_trigger_update() was introduced in "cpufreq: Rework the
scheduler hooks for triggering updates"[0]. Consensus is that this
helper is not needed and removing it will aid in experimenting with
deadline and rt capacity requests.

Instead of reverting the above patch, which includes useful renaming of
data structures and related functions, simply remove the function,
update affected kerneldoc and change rt.c and deadline.c to use
cpufreq_update_util().

[0] lkml.kernel.org/r/7541372.ciUW4go8Ux@vostro.rjw.lan

Signed-off-by: Michael Turquette <mturquette+renesas@baylibre.com>
---
 kernel/sched/cpufreq.c  | 28 ++--------------------------
 kernel/sched/deadline.c |  2 +-
 kernel/sched/rt.c       |  2 +-
 kernel/sched/sched.h    |  2 --
 4 files changed, 4 insertions(+), 30 deletions(-)

diff --git a/kernel/sched/cpufreq.c b/kernel/sched/cpufreq.c
index eecaba4..bd012c2 100644
--- a/kernel/sched/cpufreq.c
+++ b/kernel/sched/cpufreq.c
@@ -20,8 +20,8 @@ static DEFINE_PER_CPU(struct freq_update_hook *, cpufreq_freq_update_hook);
  *
  * Set and publish the freq_update_hook pointer for the given CPU.  That pointer
  * points to a struct freq_update_hook object containing a callback function
- * to call from cpufreq_trigger_update().  That function will be called from
- * an RCU read-side critical section, so it must not sleep.
+ * to call from cpufreq_update_util().  That function will be called from an
+ * RCU read-side critical section, so it must not sleep.
  *
  * Callers must use RCU-sched callbacks to free any memory that might be
  * accessed via the old update_util_data pointer or invoke synchronize_sched()
@@ -87,27 +87,3 @@ void cpufreq_update_util(u64 time, unsigned long util, unsigned long max)
 	if (hook)
 		hook->func(hook, time, util, max);
 }
-
-/**
- * cpufreq_trigger_update - Trigger CPU performance state evaluation if needed.
- * @time: Current time.
- *
- * The way cpufreq is currently arranged requires it to evaluate the CPU
- * performance state (frequency/voltage) on a regular basis.  To facilitate
- * that, cpufreq_update_util() is called by update_load_avg() in CFS when
- * executed for the current CPU's runqueue.
- *
- * However, this isn't sufficient to prevent the CPU from being stuck in a
- * completely inadequate performance level for too long, because the calls
- * from CFS will not be made if RT or deadline tasks are active all the time
- * (or there are RT and DL tasks only).
- *
- * As a workaround for that issue, this function is called by the RT and DL
- * sched classes to trigger extra cpufreq updates to prevent it from stalling,
- * but that really is a band-aid.  Going forward it should be replaced with
- * solutions targeted more specifically at RT and DL tasks.
- */
-void cpufreq_trigger_update(u64 time)
-{
-	cpufreq_update_util(time, ULONG_MAX, 0);
-}
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 1a035fa..3fd5bc4 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -728,7 +728,7 @@ static void update_curr_dl(struct rq *rq)
 
 	/* Kick cpufreq (see the comment in drivers/cpufreq/cpufreq.c). */
 	if (cpu_of(rq) == smp_processor_id())
-		cpufreq_trigger_update(rq_clock(rq));
+		cpufreq_update_util(rq_clock(rq), ULONG_MAX, 0);
 
 	/*
 	 * Consumed budget is computed considering the time as
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 9dd1c09..53ad077 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -947,7 +947,7 @@ static void update_curr_rt(struct rq *rq)
 
 	/* Kick cpufreq (see the comment in drivers/cpufreq/cpufreq.c). */
 	if (cpu_of(rq) == smp_processor_id())
-		cpufreq_trigger_update(rq_clock(rq));
+		cpufreq_update_util(rq_clock(rq), ULONG_MAX, 0);
 
 	delta_exec = rq_clock_task(rq) - curr->se.exec_start;
 	if (unlikely((s64)delta_exec <= 0))
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 7ae012e..f06dfca 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1742,9 +1742,7 @@ static inline u64 irq_time_read(int cpu)
 
 #ifdef CONFIG_CPU_FREQ
 void cpufreq_update_util(u64 time, unsigned long util, unsigned long max);
-void cpufreq_trigger_update(u64 time);
 #else
 static inline void cpufreq_update_util(u64 time, unsigned long util,
 				       unsigned long max) {}
-static inline void cpufreq_trigger_update(u64 time) {}
 #endif /* CONFIG_CPU_FREQ */
-- 
2.1.4

[toc] | [prev] | [next] | [standalone]

#1358250 — Re: [PATCH 1/8] sched/cpufreq: remove cpufreq_trigger_update()

On Sun, Mar 13, 2016 at 10:22:05PM -0700, Michael Turquette wrote:
> cpufreq_trigger_update() was introduced in "cpufreq: Rework the
> scheduler hooks for triggering updates"[0]. Consensus is that this
> helper is not needed and removing it will aid in experimenting with
> deadline and rt capacity requests.
> 
> Instead of reverting the above patch, which includes useful renaming of
> data structures and related functions, simply remove the function,
> update affected kerneldoc and change rt.c and deadline.c to use
> cpufreq_update_util().

This fails to explain how the need for these hooks is dealt with.

[toc] | [prev] | [next] | [standalone]

#1358283 — Re: [PATCH 1/8] sched/cpufreq: remove cpufreq_trigger_update()

On Tue, Mar 15, 2016 at 02:45:45PM -0700, Michael Turquette wrote:
> Quoting Peter Zijlstra (2016-03-15 14:14:48)
> > On Sun, Mar 13, 2016 at 10:22:05PM -0700, Michael Turquette wrote:
> > > cpufreq_trigger_update() was introduced in "cpufreq: Rework the
> > > scheduler hooks for triggering updates"[0]. Consensus is that this
> > > helper is not needed and removing it will aid in experimenting with
> > > deadline and rt capacity requests.
> > > 
> > > Instead of reverting the above patch, which includes useful renaming of
> > > data structures and related functions, simply remove the function,
> > > update affected kerneldoc and change rt.c and deadline.c to use
> > > cpufreq_update_util().
> > 
> > This fails to explain how the need for these hooks is dealt with.
> 
> Sorry, I don't understand your point. The removed hook,
> "cpufreq_trigger_update()" was only used in deadline.c and rt.c, and
> this patch effectively reverts Rafael's patch that introduces that
> function.
> 
> It simply does not revert the other changes in Rafael's patch, such as
> some renaming.
> 
> deadline.c and rt.c are made to use cpufreq_update_util() and pass in
> ULONG_MAX for capacity and 0 for time. This is exactly what they did
> before patch "cpufreq: Rework the scheduler hooks for triggering
> updates".

Clearly I need to learn to read again.. You're right.

[toc] | [prev] | [next] | [standalone]

#1358615 — Re: [PATCH 1/8] sched/cpufreq: remove cpufreq_trigger_update()

On Sun, Mar 13, 2016 at 10:22:05PM -0700, Michael Turquette wrote:
> cpufreq_trigger_update() was introduced in "cpufreq: Rework the
> scheduler hooks for triggering updates"[0]. Consensus is that this
> helper is not needed and removing it will aid in experimenting with
> deadline and rt capacity requests.
> 
> Instead of reverting the above patch, which includes useful renaming of
> data structures and related functions, simply remove the function,
> update affected kerneldoc and change rt.c and deadline.c to use
> cpufreq_update_util().

> -/**
> - * cpufreq_trigger_update - Trigger CPU performance state evaluation if needed.
> - * @time: Current time.
> - *
> - * The way cpufreq is currently arranged requires it to evaluate the CPU
> - * performance state (frequency/voltage) on a regular basis.  To facilitate
> - * that, cpufreq_update_util() is called by update_load_avg() in CFS when
> - * executed for the current CPU's runqueue.
> - *
> - * However, this isn't sufficient to prevent the CPU from being stuck in a
> - * completely inadequate performance level for too long, because the calls
> - * from CFS will not be made if RT or deadline tasks are active all the time
> - * (or there are RT and DL tasks only).
> - *
> - * As a workaround for that issue, this function is called by the RT and DL
> - * sched classes to trigger extra cpufreq updates to prevent it from stalling,
> - * but that really is a band-aid.  Going forward it should be replaced with
> - * solutions targeted more specifically at RT and DL tasks.
> - */
> -void cpufreq_trigger_update(u64 time)
> -{
> -	cpufreq_update_util(time, ULONG_MAX, 0);
> -}

> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index 1a035fa..3fd5bc4 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -728,7 +728,7 @@ static void update_curr_dl(struct rq *rq)
>  
>  	/* Kick cpufreq (see the comment in drivers/cpufreq/cpufreq.c). */
>  	if (cpu_of(rq) == smp_processor_id())
> -		cpufreq_trigger_update(rq_clock(rq));
> +		cpufreq_update_util(rq_clock(rq), ULONG_MAX, 0);
>  
>  	/*
>  	 * Consumed budget is computed considering the time as

OK, so take two on this, now hopefully more coherent (yay for sleep!).

So my problem is that this (update_curr_dl) is not the right location to
set DL utilization (although it might be for avg dl, see the other
email).

The only reason it lives here, is that some cpufreq governors require
'timely' calls into this hook. The comment you destroyed tries to convey
this.

We should still remove this requirement from the governors. And for
simple DL guarantees this hook is placed wrong.

[toc] | [prev] | [next] | [standalone]

#1356944 — [PATCH 5/8] sched/cpufreq: pass sched class into cpufreq_update_util

cpufreq_update_util() accepts a single utilization value which  does not
account for multiple utilization contributions from the cfs, rt & dl
scheduler classes. Begin fixing this by adding a sched_class argument to
cpufreq_update_util(), all of its call sites and the governor-specific
hooks in intel_pstate.c, cpufreq_schedutil.c and cpufreq_governor.c.

A follow-on patch will add summation of the sched_class contributions to
the schedutil governor.

Signed-off-by: Michael Turquette <mturquette+renesas@baylibre.com>
---
 drivers/cpufreq/cpufreq_governor.c  |  5 +++--
 drivers/cpufreq/cpufreq_schedutil.c |  6 ++++--
 drivers/cpufreq/intel_pstate.c      |  5 +++--
 include/linux/sched.h               | 16 +++++++++++++---
 kernel/sched/cpufreq.c              | 11 +++++++----
 kernel/sched/deadline.c             |  2 +-
 kernel/sched/fair.c                 |  2 +-
 kernel/sched/rt.c                   |  2 +-
 kernel/sched/sched.h                |  8 +++++---
 9 files changed, 38 insertions(+), 19 deletions(-)

diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c
index 148576c..4694751 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -248,8 +248,9 @@ static void dbs_irq_work(struct irq_work *irq_work)
 	schedule_work(&policy_dbs->work);
 }
 
-static void dbs_freq_update_handler(struct freq_update_hook *hook, u64 time,
-				    unsigned long util_not_used,
+static void dbs_freq_update_handler(struct freq_update_hook *hook,
+				    enum sched_class_util sc_not_used,
+				    u64 time, unsigned long util_not_used,
 				    unsigned long max_not_used)
 {
 	struct cpu_dbs_info *cdbs = container_of(hook, struct cpu_dbs_info, update_hook);
diff --git a/drivers/cpufreq/cpufreq_schedutil.c b/drivers/cpufreq/cpufreq_schedutil.c
index 12e49b9..18d9ca3 100644
--- a/drivers/cpufreq/cpufreq_schedutil.c
+++ b/drivers/cpufreq/cpufreq_schedutil.c
@@ -106,7 +106,8 @@ static void sugov_update_commit(struct sugov_policy *sg_policy, u64 time,
 	trace_cpu_frequency(freq, smp_processor_id());
 }
 
-static void sugov_update_single(struct freq_update_hook *hook, u64 time,
+static void sugov_update_single(struct freq_update_hook *hook,
+				enum sched_class_util sc, u64 time,
 				unsigned long util, unsigned long max)
 {
 	struct sugov_cpu *sg_cpu = container_of(hook, struct sugov_cpu, update_hook);
@@ -166,7 +167,8 @@ static unsigned int sugov_next_freq(struct sugov_policy *sg_policy,
 	return  util * max_f / max;
 }
 
-static void sugov_update_shared(struct freq_update_hook *hook, u64 time,
+static void sugov_update_shared(struct freq_update_hook *hook,
+				enum sched_class_util sc, u64 time,
 				unsigned long util, unsigned long max)
 {
 	struct sugov_cpu *sg_cpu = container_of(hook, struct sugov_cpu, update_hook);
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 20e2bb2..86aa368 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -1020,8 +1020,9 @@ static inline void intel_pstate_adjust_busy_pstate(struct cpudata *cpu)
 		sample->freq);
 }
 
-static void intel_pstate_freq_update(struct freq_update_hook *hook, u64 time,
-				     unsigned long util_not_used,
+static void intel_pstate_freq_update(struct freq_update_hook *hook,
+				     enum sched_class_util sc_not_used
+				     u64 time, unsigned long util_not_used,
 				     unsigned long max_not_used)
 {
 	struct cpudata *cpu = container_of(hook, struct cpudata, update_hook);
diff --git a/include/linux/sched.h b/include/linux/sched.h
index f18a99b..1c7d7bd 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2362,15 +2362,25 @@ extern u64 scheduler_tick_max_deferment(void);
 static inline bool sched_can_stop_tick(void) { return false; }
 #endif
 
+enum sched_class_util {
+	cfs_util,
+	rt_util,
+	dl_util,
+	nr_util_types,
+};
+
 #ifdef CONFIG_CPU_FREQ
 struct freq_update_hook {
-	void (*func)(struct freq_update_hook *hook, u64 time,
+	void (*func)(struct freq_update_hook *hook,
+		     enum sched_class_util sched_class, u64 time,
 		     unsigned long util, unsigned long max);
 };
 
 void cpufreq_set_freq_update_hook(int cpu, struct freq_update_hook *hook,
-			void (*func)(struct freq_update_hook *hook, u64 time,
-				     unsigned long util, unsigned long max));
+			void (*func)(struct freq_update_hook *hook,
+				     enum sched_class_util sched_class,
+				     u64 time, unsigned long util,
+				     unsigned long max));
 void cpufreq_clear_freq_update_hook(int cpu);
 unsigned long cpufreq_get_cfs_capacity_margin(void);
 void cpufreq_set_cfs_capacity_margin(unsigned long margin);
diff --git a/kernel/sched/cpufreq.c b/kernel/sched/cpufreq.c
index a126b58..87f99a6 100644
--- a/kernel/sched/cpufreq.c
+++ b/kernel/sched/cpufreq.c
@@ -39,8 +39,10 @@ static void set_freq_update_hook(int cpu, struct freq_update_hook *hook)
  * @func: Callback function to use with the new hook.
  */
 void cpufreq_set_freq_update_hook(int cpu, struct freq_update_hook *hook,
-			void (*func)(struct freq_update_hook *hook, u64 time,
-				     unsigned long util, unsigned long max))
+			void (*func)(struct freq_update_hook *hook,
+				     enum sched_class_util sched_class,
+				     u64 time, unsigned long util,
+				     unsigned long max))
 {
 	if (WARN_ON(!hook || !func))
 		return;
@@ -124,7 +126,8 @@ EXPORT_SYMBOL_GPL(cpufreq_reset_cfs_capacity_margin);
  *
  * It can only be called from RCU-sched read-side critical sections.
  */
-void cpufreq_update_util(u64 time, unsigned long util, unsigned long max)
+void cpufreq_update_util(enum sched_class_util sc, u64 time,
+			 unsigned long util, unsigned long max)
 {
 	struct freq_update_hook *hook;
 
@@ -138,5 +141,5 @@ void cpufreq_update_util(u64 time, unsigned long util, unsigned long max)
 	 * may become NULL after the check below.
 	 */
 	if (hook)
-		hook->func(hook, time, util, max);
+		hook->func(hook, sc, time, util, max);
 }
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 3fd5bc4..d88ed3f 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -728,7 +728,7 @@ static void update_curr_dl(struct rq *rq)
 
 	/* Kick cpufreq (see the comment in drivers/cpufreq/cpufreq.c). */
 	if (cpu_of(rq) == smp_processor_id())
-		cpufreq_update_util(rq_clock(rq), ULONG_MAX, 0);
+		cpufreq_update_util(dl_util, rq_clock(rq), ULONG_MAX, 0);
 
 	/*
 	 * Consumed budget is computed considering the time as
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 29e8bae..6b454bc 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2867,7 +2867,7 @@ static inline void update_load_avg(struct sched_entity *se, int update_tg)
 		 * thread is a different class (!fair), nor will the utilization
 		 * number include things like RT tasks.
 		 */
-		cpufreq_update_util(rq_clock(rq), min(cap, max), max);
+		cpufreq_update_util(cfs_util, rq_clock(rq), min(cap, max), max);
 	}
 }
 
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 53ad077..9d9dab4 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -947,7 +947,7 @@ static void update_curr_rt(struct rq *rq)
 
 	/* Kick cpufreq (see the comment in drivers/cpufreq/cpufreq.c). */
 	if (cpu_of(rq) == smp_processor_id())
-		cpufreq_update_util(rq_clock(rq), ULONG_MAX, 0);
+		cpufreq_update_util(rt_util, rq_clock(rq), ULONG_MAX, 0);
 
 	delta_exec = rq_clock_task(rq) - curr->se.exec_start;
 	if (unlikely((s64)delta_exec <= 0))
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 8c93ed2..469d11d 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1744,8 +1744,10 @@ static inline u64 irq_time_read(int cpu)
 #endif /* CONFIG_IRQ_TIME_ACCOUNTING */
 
 #ifdef CONFIG_CPU_FREQ
-void cpufreq_update_util(u64 time, unsigned long util, unsigned long max);
+void cpufreq_update_util(enum sched_class_util sc, u64 time,
+			 unsigned long util, unsigned long max);
 #else
-static inline void cpufreq_update_util(u64 time, unsigned long util,
-				       unsigned long max) {}
+static inline void cpufreq_update_util(enum sched_class_util sc, u64 time,
+				       unsigned long util, unsigned long max)
+{}
 #endif /* CONFIG_CPU_FREQ */
-- 
2.1.4

[toc] | [prev] | [next] | [standalone]

#1358254 — Re: [PATCH 5/8] sched/cpufreq: pass sched class into cpufreq_update_util

On Sun, Mar 13, 2016 at 10:22:09PM -0700, Michael Turquette wrote:
> +++ b/include/linux/sched.h
> @@ -2362,15 +2362,25 @@ extern u64 scheduler_tick_max_deferment(void);
>  static inline bool sched_can_stop_tick(void) { return false; }
>  #endif
>  
> +enum sched_class_util {
> +	cfs_util,
> +	rt_util,
> +	dl_util,
> +	nr_util_types,
> +};
> +
>  #ifdef CONFIG_CPU_FREQ
>  struct freq_update_hook {
> +	void (*func)(struct freq_update_hook *hook,
> +		     enum sched_class_util sched_class, u64 time,
>  		     unsigned long util, unsigned long max);
>  };
>  
>  void cpufreq_set_freq_update_hook(int cpu, struct freq_update_hook *hook,
> +			void (*func)(struct freq_update_hook *hook,
> +				     enum sched_class_util sched_class,
> +				     u64 time, unsigned long util,
> +				     unsigned long max));

Have you looked at the asm that generated? At some point you'll start
spilling on the stack and it'll be a god awful mess.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.kernel

csiph-web