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

Groups > linux.kernel > #1340127 > unrolled thread

[RFCv7 PATCH 00/10] sched: scheduler-driven CPU frequency selection

Back to article view | Back to linux.kernel

Contents

  [RFCv7 PATCH 00/10] sched: scheduler-driven CPU frequency selection Steve Muckle <steve.muckle@linaro.org> - 2016-02-23 02:30 +0100
    [RFCv7 PATCH 07/10] sched/fair: jump to max OPP when crossing UP threshold Steve Muckle <steve.muckle@linaro.org> - 2016-02-23 02:30 +0100
    [RFCv7 PATCH 09/10] sched/deadline: split rt_avg in 2 distincts metrics Steve Muckle <steve.muckle@linaro.org> - 2016-02-23 02:30 +0100
    [RFCv7 PATCH 10/10] sched: rt scheduler sets capacity requirement Steve Muckle <steve.muckle@linaro.org> - 2016-02-23 02:30 +0100
    [RFCv7 PATCH 08/10] sched: remove call of sched_avg_update from sched_rt_avg_update Steve Muckle <steve.muckle@linaro.org> - 2016-02-23 02:30 +0100
    [RFCv7 PATCH 02/10] cpufreq: introduce cpufreq_driver_is_slow Steve Muckle <steve.muckle@linaro.org> - 2016-02-23 02:30 +0100
      Re: [RFCv7 PATCH 02/10] cpufreq: introduce cpufreq_driver_is_slow "Rafael J. Wysocki" <rafael@kernel.org> - 2016-02-23 02:40 +0100
        Re: [RFCv7 PATCH 02/10] cpufreq: introduce cpufreq_driver_is_slow Michael Turquette <mturquette@baylibre.com> - 2016-02-26 02:10 +0100
          Re: [RFCv7 PATCH 02/10] cpufreq: introduce cpufreq_driver_is_slow "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-02-26 02:20 +0100
            Re: [RFCv7 PATCH 02/10] cpufreq: introduce cpufreq_driver_is_slow "Rafael J. Wysocki" <rafael@kernel.org> - 2016-02-26 22:10 +0100
          Re: [RFCv7 PATCH 02/10] cpufreq: introduce cpufreq_driver_is_slow Steve Muckle <steve.muckle@linaro.org> - 2016-02-26 02:20 +0100
    [RFCv7 PATCH 06/10] sched/fair: cpufreq_sched triggers for load balancing Steve Muckle <steve.muckle@linaro.org> - 2016-02-23 02:30 +0100
    [RFCv7 PATCH 04/10] sched/fair: add triggers for OPP change requests Steve Muckle <steve.muckle@linaro.org> - 2016-02-23 02:30 +0100
      Re: [RFCv7 PATCH 04/10] sched/fair: add triggers for OPP change requests Ricky Liang <jcliang@chromium.org> - 2016-03-01 08:00 +0100
        Re: [RFCv7 PATCH 04/10] sched/fair: add triggers for OPP change  requests Steve Muckle <steve.muckle@linaro.org> - 2016-03-03 05:00 +0100
    [RFCv7 PATCH 03/10] sched: scheduler-driven cpu frequency selection Steve Muckle <steve.muckle@linaro.org> - 2016-02-23 02:30 +0100
      Re: [RFCv7 PATCH 03/10] sched: scheduler-driven cpu frequency selection "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-02-25 05:00 +0100
        Re: [RFCv7 PATCH 03/10] sched: scheduler-driven cpu frequency  selection Peter Zijlstra <peterz@infradead.org> - 2016-02-25 10:30 +0100
          Re: [RFCv7 PATCH 03/10] sched: scheduler-driven cpu frequency selection "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-02-25 22:10 +0100
        Re: [RFCv7 PATCH 03/10] sched: scheduler-driven cpu frequency  selection Peter Zijlstra <peterz@infradead.org> - 2016-02-25 10:30 +0100
          Re: [RFCv7 PATCH 03/10] sched: scheduler-driven cpu frequency selection "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-02-25 22:10 +0100
            Re: [RFCv7 PATCH 03/10] sched: scheduler-driven cpu frequency  selection Peter Zijlstra <peterz@infradead.org> - 2016-02-26 10:20 +0100
              Re: [RFCv7 PATCH 03/10] sched: scheduler-driven cpu frequency selection "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-02-27 01:10 +0100
                Re: [RFCv7 PATCH 03/10] sched: scheduler-driven cpu frequency  selection Peter Zijlstra <peterz@infradead.org> - 2016-03-01 14:00 +0100
                  Re: [RFCv7 PATCH 03/10] sched: scheduler-driven cpu frequency selection "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-01 20:50 +0100
        Re: [RFCv7 PATCH 03/10] sched: scheduler-driven cpu frequency selection "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-02-25 12:10 +0100
        Re: [RFCv7 PATCH 03/10] sched: scheduler-driven cpu frequency  selection Steve Muckle <steve.muckle@linaro.org> - 2016-02-26 01:40 +0100
          Re: [RFCv7 PATCH 03/10] sched: scheduler-driven cpu frequency selection "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-02-27 03:40 +0100
            Re: [RFCv7 PATCH 03/10] sched: scheduler-driven cpu frequency  selection Steve Muckle <steve.muckle@linaro.org> - 2016-02-27 05:20 +0100
              Re: [RFCv7 PATCH 03/10] sched: scheduler-driven cpu frequency selection "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-02-28 03:30 +0100
                Re: [RFCv7 PATCH 03/10] sched: scheduler-driven cpu frequency  selection Peter Zijlstra <peterz@infradead.org> - 2016-03-01 15:40 +0100
                  Re: [RFCv7 PATCH 03/10] sched: scheduler-driven cpu frequency selection "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-01 21:40 +0100
              Re: [RFCv7 PATCH 03/10] sched: scheduler-driven cpu frequency  selection Peter Zijlstra <peterz@infradead.org> - 2016-03-01 14:30 +0100
          Re: [RFCv7 PATCH 03/10] sched: scheduler-driven cpu frequency  selection Peter Zijlstra <peterz@infradead.org> - 2016-03-01 14:20 +0100
          Re: [RFCv7 PATCH 03/10] sched: scheduler-driven cpu frequency selection Michael Turquette <mturquette@baylibre.com> - 2016-03-02 08:50 +0100
            Re: [RFCv7 PATCH 03/10] sched: scheduler-driven cpu frequency selection "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-03 03:50 +0100
              Re: [RFCv7 PATCH 03/10] sched: scheduler-driven cpu frequency  selection Steve Muckle <steve.muckle@linaro.org> - 2016-03-03 05:00 +0100
                Re: [RFCv7 PATCH 03/10] sched: scheduler-driven cpu frequency  selection Juri Lelli <Juri.Lelli@arm.com> - 2016-03-03 10:40 +0100
            Re: [RFCv7 PATCH 03/10] sched: scheduler-driven cpu frequency  selection Peter Zijlstra <peterz@infradead.org> - 2016-03-03 14:10 +0100
      Re: [RFCv7 PATCH 03/10] sched: scheduler-driven cpu frequency  selection Ingo Molnar <mingo@kernel.org> - 2016-03-03 15:30 +0100
    [RFCv7 PATCH 05/10] sched/{core,fair}: trigger OPP change request on fork() Steve Muckle <steve.muckle@linaro.org> - 2016-02-23 02:30 +0100
    [RFCv7 PATCH 01/10] sched: Compute cpu capacity available at current frequency Steve Muckle <steve.muckle@linaro.org> - 2016-02-23 02:30 +0100
      Re: [RFCv7 PATCH 01/10] sched: Compute cpu capacity available at  current frequency "Rafael J. Wysocki" <rafael@kernel.org> - 2016-02-23 02:50 +0100
        Re: [RFCv7 PATCH 01/10] sched: Compute cpu capacity available at  current frequency Peter Zijlstra <peterz@infradead.org> - 2016-02-23 10:20 +0100
          Re: [RFCv7 PATCH 01/10] sched: Compute cpu capacity available at current frequency "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-02-26 02:40 +0100
            Re: [RFCv7 PATCH 01/10] sched: Compute cpu capacity available at  current frequency Peter Zijlstra <peterz@infradead.org> - 2016-02-26 10:20 +0100
    Re: [RFCv7 PATCH 00/10] sched: scheduler-driven CPU frequency  selection Steve Muckle <steve.muckle@linaro.org> - 2016-02-23 02:40 +0100

Page 3 of 3 — ← Prev page 1 2 [3]

#1340143 — [RFCv7 PATCH 05/10] sched/{core,fair}: trigger OPP change request on fork()

From: Juri Lelli <juri.lelli@arm.com>

Patch "sched/fair: add triggers for OPP change requests" introduced OPP
change triggers for enqueue_task_fair(), but the trigger was operating only
for wakeups. Fact is that it makes sense to consider wakeup_new also (i.e.,
fork()), as we don't know anything about a newly created task and thus we
most certainly want to jump to max OPP to not harm performance too much.

However, it is not currently possible (or at least it wasn't evident to me
how to do so :/) to tell new wakeups from other (non wakeup) operations.

This patch introduces an additional flag in sched.h that is only set at
fork() time and it is then consumed in enqueue_task_fair() for our purpose.

cc: Ingo Molnar <mingo@redhat.com>
cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Juri Lelli <juri.lelli@arm.com>
Signed-off-by: Steve Muckle <smuckle@linaro.org>
---
 kernel/sched/core.c  | 2 +-
 kernel/sched/fair.c  | 9 +++------
 kernel/sched/sched.h | 1 +
 3 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 87ca0be..86297a2 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2553,7 +2553,7 @@ void wake_up_new_task(struct task_struct *p)
 #endif
 
 	rq = __task_rq_lock(p);
-	activate_task(rq, p, 0);
+	activate_task(rq, p, ENQUEUE_WAKEUP_NEW);
 	p->on_rq = TASK_ON_RQ_QUEUED;
 	trace_sched_wakeup_new(p);
 	check_preempt_curr(rq, p, WF_FORK);
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index f1f00a4..e7fab8f 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4308,7 +4308,8 @@ enqueue_task_fair(struct rq *rq, struct task_struct *p, int flags)
 {
 	struct cfs_rq *cfs_rq;
 	struct sched_entity *se = &p->se;
-	int task_new = !(flags & ENQUEUE_WAKEUP);
+	int task_new = flags & ENQUEUE_WAKEUP_NEW;
+	int task_wakeup = flags & ENQUEUE_WAKEUP;
 
 	for_each_sched_entity(se) {
 		if (se->on_rq)
@@ -4349,12 +4350,8 @@ enqueue_task_fair(struct rq *rq, struct task_struct *p, int flags)
 		 * because we get here also during load balancing, but
 		 * in these cases it seems wise to trigger as single
 		 * request after load balancing is done.
-		 *
-		 * XXX: how about fork()? Do we need a special
-		 *      flag/something to tell if we are here after a
-		 *      fork() (wakeup_task_new)?
 		 */
-		if (!task_new)
+		if (task_new || task_wakeup)
 			update_capacity_of(cpu_of(rq));
 	}
 	hrtick_update(rq);
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 17908dd..9c26be2 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1140,6 +1140,7 @@ extern const u32 sched_prio_to_wmult[40];
 #endif
 #define ENQUEUE_REPLENISH	0x08
 #define ENQUEUE_RESTORE	0x10
+#define ENQUEUE_WAKEUP_NEW	0x20
 
 #define DEQUEUE_SLEEP		0x01
 #define DEQUEUE_SAVE		0x02
-- 
2.4.10

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

#1340145 — [RFCv7 PATCH 01/10] sched: Compute cpu capacity available at current frequency

From: Morten Rasmussen <morten.rasmussen@arm.com>

capacity_orig_of() returns the max available compute capacity of a cpu.
For scale-invariant utilization tracking and energy-aware scheduling
decisions it is useful to know the compute capacity available at the
current OPP of a cpu.

cc: Ingo Molnar <mingo@redhat.com>
cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Morten Rasmussen <morten.rasmussen@arm.com>
Signed-off-by: Steve Muckle <smuckle@linaro.org>
---
 kernel/sched/fair.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 7ce24a4..3437e01 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4821,6 +4821,17 @@ static long effective_load(struct task_group *tg, int cpu, long wl, long wg)
 #endif
 
 /*
+ * Returns the current capacity of cpu after applying both
+ * cpu and freq scaling.
+ */
+static unsigned long capacity_curr_of(int cpu)
+{
+	return cpu_rq(cpu)->cpu_capacity_orig *
+	       arch_scale_freq_capacity(NULL, cpu)
+	       >> SCHED_CAPACITY_SHIFT;
+}
+
+/*
  * Detect M:N waker/wakee relationships via a switching-frequency heuristic.
  * A waker of many should wake a different task than the one last awakened
  * at a frequency roughly N times higher than one of its wakees.  In order
-- 
2.4.10

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

#1340167 — Re: [RFCv7 PATCH 01/10] sched: Compute cpu capacity available at current frequency

On Tue, Feb 23, 2016 at 2:22 AM, Steve Muckle <steve.muckle@linaro.org> wrote:
> From: Morten Rasmussen <morten.rasmussen@arm.com>
>
> capacity_orig_of() returns the max available compute capacity of a cpu.
> For scale-invariant utilization tracking and energy-aware scheduling
> decisions it is useful to know the compute capacity available at the
> current OPP of a cpu.
>
> cc: Ingo Molnar <mingo@redhat.com>
> cc: Peter Zijlstra <peterz@infradead.org>
> Signed-off-by: Morten Rasmussen <morten.rasmussen@arm.com>
> Signed-off-by: Steve Muckle <smuckle@linaro.org>
> ---
>  kernel/sched/fair.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 7ce24a4..3437e01 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4821,6 +4821,17 @@ static long effective_load(struct task_group *tg, int cpu, long wl, long wg)
>  #endif
>
>  /*
> + * Returns the current capacity of cpu after applying both
> + * cpu and freq scaling.
> + */
> +static unsigned long capacity_curr_of(int cpu)
> +{
> +       return cpu_rq(cpu)->cpu_capacity_orig *
> +              arch_scale_freq_capacity(NULL, cpu)

What about architectures that don't have this?

Why is that an architecture feature?

I can easily imagine two x86 platforms using different
scale_freq_capacity(), for example.

> +              >> SCHED_CAPACITY_SHIFT;
> +}
> +
> +/*
>   * Detect M:N waker/wakee relationships via a switching-frequency heuristic.
>   * A waker of many should wake a different task than the one last awakened
>   * at a frequency roughly N times higher than one of its wakees.  In order
> --


Thanks,
Rafael

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

#1340449 — Re: [RFCv7 PATCH 01/10] sched: Compute cpu capacity available at current frequency

On Tue, Feb 23, 2016 at 02:41:20AM +0100, Rafael J. Wysocki wrote:
> >  /*
> > + * Returns the current capacity of cpu after applying both
> > + * cpu and freq scaling.
> > + */
> > +static unsigned long capacity_curr_of(int cpu)
> > +{
> > +       return cpu_rq(cpu)->cpu_capacity_orig *
> > +              arch_scale_freq_capacity(NULL, cpu)
> 
> What about architectures that don't have this?

They get the 'default' which is a constant SCHED_CAPACITY_SCALE unit.

> Why is that an architecture feature?

Because not all archs can tell the frequency the same way. Some you
program the DVFS state and they really run at this speed, for those you
can simply report back.

For others, x86 for example, you program a DVFS 'hint' and the hardware
does whatever, we'd have to do APERF/MPERF samples to get an idea of the
actual frequency we ran at.

Also, the having of this makes the load tracking slightly more
expensive, instead of compile time constants we get function calls and
actual multiplications. Its not _too_ bad, but still.

> I can easily imagine two x86 platforms using different
> scale_freq_capacity(), for example.

That's up to the arch, if different x86 platforms need different
thingies the arch implementation needs to offer a selector -- this isn't
'hard'.

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

#1343714 — Re: [RFCv7 PATCH 01/10] sched: Compute cpu capacity available at current frequency

On Tuesday, February 23, 2016 10:19:16 AM Peter Zijlstra wrote:
> On Tue, Feb 23, 2016 at 02:41:20AM +0100, Rafael J. Wysocki wrote:
> > >  /*
> > > + * Returns the current capacity of cpu after applying both
> > > + * cpu and freq scaling.
> > > + */
> > > +static unsigned long capacity_curr_of(int cpu)
> > > +{
> > > +       return cpu_rq(cpu)->cpu_capacity_orig *
> > > +              arch_scale_freq_capacity(NULL, cpu)
> > 
> > What about architectures that don't have this?
> 
> They get the 'default' which is a constant SCHED_CAPACITY_SCALE unit.
> 
> > Why is that an architecture feature?
> 
> Because not all archs can tell the frequency the same way. Some you
> program the DVFS state and they really run at this speed, for those you
> can simply report back.
> 
> For others, x86 for example, you program a DVFS 'hint' and the hardware
> does whatever, we'd have to do APERF/MPERF samples to get an idea of the
> actual frequency we ran at.
> 
> Also, the having of this makes the load tracking slightly more
> expensive, instead of compile time constants we get function calls and
> actual multiplications. Its not _too_ bad, but still.

That's all correct, but my question should rather be: is arch the right
granularity?

In theory, there may be ARM64-based platforms using ACPI and behaving
like x86 in that respect in the future.

Thanks,
Rafael

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

#1343936 — Re: [RFCv7 PATCH 01/10] sched: Compute cpu capacity available at current frequency

On Fri, Feb 26, 2016 at 02:37:19AM +0100, Rafael J. Wysocki wrote:

> That's all correct, but my question should rather be: is arch the right
> granularity?
> 
> In theory, there may be ARM64-based platforms using ACPI and behaving
> like x86 in that respect in the future.

Ah, so I started these hooks way before the cpufreq/cpuidle etc.
integration push.

Maybe we should look at something like that, but performance is really
critical, you most definitely do not want 3 indirections just because
abstract framework crap, that's measurable overhead on these callsites.

Hence the current inline with constant value or single function call.
And if archs would want a selector, I would recommend boot time call
instruction rewrites a-la alternatives/paravirt.

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

#1340163 — Re: [RFCv7 PATCH 00/10] sched: scheduler-driven CPU frequency selection

On 02/22/2016 05:22 PM, Steve Muckle wrote:
> Scheduler-driven CPU frequency selection hopes to exploit both
> per-task and global information in the scheduler to improve frequency
> selection policy and achieve lower power consumption, improved
> responsiveness/performance, and less reliance on heuristics and
> tunables. For further discussion of this integration see [0].
> 
> This patch series implements a cpufreq governor which collects CPU
> capacity requests from the fair, realtime, and deadline scheduling
> classes. The fair and realtime scheduling classes are modified to make
> these requests. The deadline class is not yet modified to make CPU
> capacity requests.

This RFC series does not attempt to address any of today's feedback
regarding simplifying the hooks in the scheduler - I'd like some more
time to ponder that. But I thought it important to get the latest
version of this out for discussion as soon as possible.

thanks,
Steve

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | linux.kernel

csiph-web