linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Douglas RAILLARD <douglas.raillard@arm.com>
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	mingo@redhat.com, rjw@rjwysocki.net, viresh.kumar@linaro.org,
	quentin.perret@arm.com, patrick.bellasi@arm.com,
	dietmar.eggemann@arm.com
Subject: Re: [RFC PATCH v2 0/5] sched/cpufreq: Make schedutil energy aware
Date: Tue, 2 Jul 2019 17:51:15 +0200	[thread overview]
Message-ID: <20190702155115.GW3436@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20190627171603.14767-1-douglas.raillard@arm.com>

On Thu, Jun 27, 2019 at 06:15:58PM +0100, Douglas RAILLARD wrote:
> Make schedutil cpufreq governor energy-aware.
> 
> - patch 4 adds sugov_cpu_ramp_boost() function.
> - patch 5 updates sugov_update_(single|shared)() to make use of
>   sugov_cpu_ramp_boost().
> 
> The benefits of using the EM in schedutil are twofold:

> 2) Driving the frequency selection with power in mind, in addition to
>    maximizing the utilization of the non-idle CPUs in the system.

> Point 2) is enabled in
> "sched/cpufreq: Boost schedutil frequency ramp up". It allows using
> higher frequencies when it is known that the true utilization of
> currently running tasks is exceeding their previous stable point.
> The benefits are:
> 
> * Boosting the frequency when the behavior of a runnable task changes,
>   leading to an increase in utilization. That shortens the frequency
>   ramp up duration, which in turns allows the utilization signal to
>   reach stable values quicker.  Since the allowed frequency boost is
>   bounded in energy, it will behave consistently across platforms,
>   regardless of the OPP cost range.
> 
> * The boost is only transient, and should not impact a lot the energy
>   consumed of workloads with very stable utilization signals.

So you're allowing a higher pick when the EWMA exceeds the enqueue
thing.

This then obviously has relation to Patrick's patch that makes the EWMA
asymmetric, but I'm thinking that the interaction is mostly favourable?

I'm not immediately seeing how it is transient; that is, PELT has a
wobble in it's steady state, is that accounted for?

  parent reply	other threads:[~2019-07-02 15:51 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-27 17:15 [RFC PATCH v2 0/5] sched/cpufreq: Make schedutil energy aware Douglas RAILLARD
2019-06-27 17:15 ` [RFC PATCH v2 1/5] PM: Introduce em_pd_get_higher_freq() Douglas RAILLARD
2019-06-27 17:16 ` [RFC PATCH v2 2/5] sched/cpufreq: Attach perf domain to sugov policy Douglas RAILLARD
2019-06-27 17:16 ` [RFC PATCH v2 3/5] sched/cpufreq: Hook em_pd_get_higher_power() into get_next_freq() Douglas RAILLARD
2019-06-27 17:16 ` [RFC PATCH v2 4/5] sched/cpufreq: Introduce sugov_cpu_ramp_boost Douglas RAILLARD
2019-06-28 15:08   ` Patrick Bellasi
2019-06-27 17:16 ` [RFC PATCH v2 5/5] sched/cpufreq: Boost schedutil frequency ramp up Douglas RAILLARD
2019-07-02 15:44 ` [RFC PATCH v2 0/5] sched/cpufreq: Make schedutil energy aware Peter Zijlstra
2019-07-03 13:38   ` Douglas Raillard
2019-07-08 11:13     ` Patrick Bellasi
2019-07-08 13:49       ` Douglas Raillard
2019-07-02 15:51 ` Peter Zijlstra [this message]
2019-07-03 16:36   ` Douglas Raillard
2019-07-08 11:09     ` Patrick Bellasi
2019-07-08 13:46       ` Douglas Raillard
2019-07-09 10:37         ` Patrick Bellasi
2019-08-09 17:37           ` Douglas Raillard

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=20190702155115.GW3436@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=dietmar.eggemann@arm.com \
    --cc=douglas.raillard@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=patrick.bellasi@arm.com \
    --cc=quentin.perret@arm.com \
    --cc=rjw@rjwysocki.net \
    --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).