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


Groups > linux.kernel > #1352905

Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data

From Peter Zijlstra <peterz@infradead.org>
Newsgroups linux.kernel
Subject Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data
Date 2016-03-08 12:30 +0100
Message-ID <ranZU-8V-29@gated-at.bofh.it> (permalink)
References <r84I2-18B-15@gated-at.bofh.it> <r8I2K-3U3-3@gated-at.bofh.it> <r8J8u-4LK-11@gated-at.bofh.it> <r9Tfr-576-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Mon, Mar 07, 2016 at 03:41:15AM +0100, Rafael J. Wysocki wrote:

> If my understanding of the requency invariant utilization idea is correct,
> it is about re-scaling utilization so it is always relative to the capacity
> at the max frequency.

Right. So if a workload runs for 5ms at @1GHz and 10ms @500MHz, it would
still result in the exact same utilization.

> If that's the case, then instead of using
>   x = util_raw / max
> we will use something like
>   y = (util_raw / max) * (f / max_freq) (f - current frequency).

I don't get the last term. Assuming fixed frequency hardware (we can't
really assume anything else) I get to:

  util = util_raw * (current_freq / max_freq)		(1)
  x = util / max					(2)

> so there's no hope that the same formula will ever work for both "raw"
> and "frequency invariant" utilization.

Here I agree, however the above (current_freq / max_freq) term is easily
computable, and really the only thing we can assume if the arch doesn't
implement freq invariant accounting.

> (c) Code for using either "raw" or "frequency invariant" depending on
>     a callback flag or something like that.

Seeing how frequency invariance is an arch feature, and cpufreq drivers
are also typically arch specific, do we really need a flag at this
level?

In any case, I think the only difference between the two formula should
be the addition of (1) for the platforms that do not already implement
frequency invariance.

That is actually correct for platforms which do as told with their DVFS
bits. And there's really not much else we can do short of implementing
the scheduler arch hook to do better.

> (b) Make all architecuters use "frequency invariant" and then look for a
>     working formula (seems rather less than realistic to me to be honest).

There was a proposal to implement arch_scale_freq_capacity() as a weak
function and have it serve the cpufreq selected frequency for (1) so
that everything would default to that.

We didn't do that because that makes the function call and
multiplications unconditional. It's cheaper to add (1) to the cpufreq
side when selecting a freq rather than at every single time we update
the util statistics.

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-07 03:40 +0100
  Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler  utilization data Peter Zijlstra <peterz@infradead.org> - 2016-03-08 12:30 +0100
    Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler  utilization data "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-08 19:10 +0100
      Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler  utilization data Peter Zijlstra <peterz@infradead.org> - 2016-03-08 20:30 +0100
        Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler  utilization data "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-08 21:10 +0100
          Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler  utilization data Juri Lelli <juri.lelli@arm.com> - 2016-03-09 11:20 +0100
            Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler  utilization data "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-10 00:50 +0100
              Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler  utilization data Juri Lelli <juri.lelli@arm.com> - 2016-03-10 05:40 +0100
                Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-10 22:10 +0100
              Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler  utilization data Michael Turquette <mturquette@baylibre.com> - 2016-03-11 00:30 +0100
          Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler  utilization data Peter Zijlstra <peterz@infradead.org> - 2016-03-09 17:40 +0100
            Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler  utilization data "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-10 00:30 +0100
              Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler  utilization data Vincent Guittot <vincent.guittot@linaro.org> - 2016-03-10 04:50 +0100
                Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler  utilization data Peter Zijlstra <peterz@infradead.org> - 2016-03-10 11:10 +0100
                Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler  utilization data Vincent Guittot <vincent.guittot@linaro.org> - 2016-03-10 11:30 +0100
                Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler  utilization data Peter Zijlstra <peterz@infradead.org> - 2016-03-10 11:40 +0100
                Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler  utilization data Peter Zijlstra <peterz@infradead.org> - 2016-03-10 12:00 +0100
                Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-10 23:30 +0100
              Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler  utilization data Peter Zijlstra <peterz@infradead.org> - 2016-03-10 09:50 +0100

csiph-web