linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Douglas Raillard <douglas.raillard@arm.com>
To: linux-kernel@vger.kernel.org, rjw@rjwysocki.net,
	viresh.kumar@linaro.org, peterz@infradead.org,
	juri.lelli@redhat.com, vincent.guittot@linaro.org
Cc: dietmar.eggemann@arm.com, qperret@google.com, linux-pm@vger.kernel.org
Subject: Re: [RFC PATCH v4 3/6] sched/cpufreq: Hook em_pd_get_higher_power() into get_next_freq()
Date: Thu, 27 Feb 2020 15:51:34 +0000	[thread overview]
Message-ID: <5d732dc1-d343-24d2-bda9-072021a510ed@arm.com> (raw)
In-Reply-To: <20200122173538.1142069-4-douglas.raillard@arm.com>

Let's this thread be about util boosting vs energy boosting.

Short recap of the conversation:

Peter:
>>> (I have vague memories of this (the util boosting) being proposed
earlier; it also avoids
>>> that double OPP iteration thing complained about elsewhere in this
>>> thread if I'm not mistaken).
>>

Douglas:
>> It should be possible to get rid of the double iteration mentioned by
>> Quentin. Choosing to boost the util or the energy boils down to:
>>
>> 1) If you care more about predictable battery life (or energy bill) than
>> predictability of the boost feature, EM should be used.
>>
>> 2) If you don't have an EM or you care more about having a predictable
>> boost for a given workload, use util (or disable that boost).
>>
>> The rational is that with 1), you will get a different speed boost for a
>> given workload depending on the other things executing at the same time,
>> as the speed up is not linear with the task-related metric (util -
>> util_est). If you are already at high freq because of another workload,
>> the speed up will be small because the next 100Mhz will cost much more
>> than the same +100Mhz delta starting from a low OPP.

Peter:
>
> It's just that I'm not seeing how 1 actually works or provides that more
> predictable battery life I suppose. We have this other sub-thread to
> argue about that :-)

Here is a more detailed version of util boost vs energy boost.
The goal of what follows is to show that util-based boost gives predictable
performance speedup, while energy-based boost gives predictable increase in
energy consumption.

In both cases, the boost value is computed as (util - ue.enqueued),
and only its interpretation differs:
* as an increase in util for util-based boost
* as an OPP cost margin for the energy-based boost



util(wload) = util_avg(wload)
util_est_enqueued(wload)
	| wload is enqueued = f(util_avg(wload))
	| otherwise         = 0

(wloadA + wloadB) denotes a "virtual" task that is running whenever either
wloadA or wloadB is running.

# Assuming wloadA and wloadB are attached to the same rq:
util(wloadA + wloadB) = util(wloadA) + util(wloadB)

# Assuming wloadA and wloadB do not preempt each other:
util_est_enqueued(wloadA + wloadB) =
	util_est_enqueued(wloadA) + util_est_enqueued(wloadB)

# boostU(wload) is the increase of util due to the util-based boost.
# boostE(wload) is the increase of *util* due to the energy-based boost.

boostU(wload) 
	| wload enqueued and util(wload) > util_est_enqueued(wload) =
		util(wload) - util_est_enqueued(wload)
	| otherwise = 0

boostU(wloadA + wloadB) = util(wloadA + wloadB) -
    util_est_enqueued(wloadA + wloadB)
boostU(wloadA + wloadB) = util(wloadA) + util(wloadB) -
    util_est_enqueued(wloadA) - util_est_enqueued(wloadB)
boostU(wloadA + wloadB) = boostU(wloadA) + boostU(wloadB)

# Now if we now intepret the same boost value as a freq energy cost margin:
boostE(wload) 
	| wload enqueued and util(wload) > util_est_enqueued(wload) =
		apply_boostE(util(wload), util_est_enqueued(wload), map_util_freq(util(wload)))
	| otherwise = 0

# with:
apply_boostE(util, util_est_enqueued, base_freq) = 
	boost = util - util_est_enqueued
	boosted_freq = freq_at(boost + cost_of(base_freq))
	freq_delta = boosted_freq - base_freq
	speedup = 1 + freq_delta / max_freq
	return util * speedup

Since freq_at(cost) function is not a linear function of cost
and util(wloadA + wloadB) = util(wloadA) + util(wloadB),
apply_boostE() is not a linear function of wload, which means:
boostE(wloadA + wloadB) != boostE(wloadA) + boostE(wloadB)

This means the speedup (util increase) given by boostE cannot be evaluated for
one task without considering all other attached tasks on the same rq. Therefore
the speedup introduced by boostE is not easily predictable.

On the other hand, the increase in energy cost is linear in the workload for
energy-based boost. but not linear for the util-based boost.

That made me realize that to achieve that, EM_COST_MARGIN_SCALE needs to
map to the highest cost in the system, not the highest cost of the
current CPU, I will fix that.

Also, util_est_enqueued is not linear in the general case when wloadA and
wloadB preempt each-other. There could be ways of making that work but it's
probably a better idea to move the logic at the task level and aggregate the
flag at runqueue level. This will also allow the boost to work when the set of
enqueued tasks varies, which is likely to happen in a real system.


  parent reply	other threads:[~2020-02-27 15:51 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-22 17:35 [RFC PATCH v4 0/6] sched/cpufreq: Make schedutil energy aware Douglas RAILLARD
2020-01-22 17:35 ` [RFC PATCH v4 1/6] PM: Introduce em_pd_get_higher_freq() Douglas RAILLARD
2020-01-22 17:35 ` [RFC PATCH v4 2/6] sched/cpufreq: Attach perf domain to sugov policy Douglas RAILLARD
2020-01-22 17:35 ` [RFC PATCH v4 3/6] sched/cpufreq: Hook em_pd_get_higher_power() into get_next_freq() Douglas RAILLARD
2020-01-23 16:16   ` Quentin Perret
2020-01-23 17:52     ` Douglas Raillard
2020-01-24 14:37       ` Quentin Perret
2020-01-24 14:58         ` Quentin Perret
2020-02-27 15:51   ` Douglas Raillard [this message]
2020-01-22 17:35 ` [RFC PATCH v4 4/6] sched/cpufreq: Introduce sugov_cpu_ramp_boost Douglas RAILLARD
2020-01-23 15:55   ` Rafael J. Wysocki
2020-01-23 17:21     ` Douglas Raillard
2020-01-23 21:02       ` Rafael J. Wysocki
2020-01-28 15:38         ` Douglas Raillard
2020-02-10 13:08   ` Peter Zijlstra
2020-02-13 10:49     ` Douglas Raillard
2020-01-22 17:35 ` [RFC PATCH v4 5/6] sched/cpufreq: Boost schedutil frequency ramp up Douglas RAILLARD
2020-01-22 17:35 ` [RFC PATCH v4 6/6] sched/cpufreq: Add schedutil_em_tp tracepoint Douglas RAILLARD
2020-01-22 18:14 ` [RFC PATCH v4 0/6] sched/cpufreq: Make schedutil energy aware Douglas Raillard
2020-02-10 13:21   ` Peter Zijlstra
2020-02-13 17:49     ` Douglas Raillard
2020-02-14 12:21       ` Peter Zijlstra
2020-02-14 12:52       ` Peter Zijlstra
2020-03-11 12:25         ` Douglas Raillard
2020-02-14 13:37       ` Peter Zijlstra
2020-03-11 12:40         ` Douglas Raillard
2020-01-23 15:43 ` Rafael J. Wysocki
2020-01-23 17:16   ` Douglas Raillard
2020-02-10 13:30     ` Peter Zijlstra
2020-02-13 11:55       ` Douglas Raillard
2020-02-13 13:20         ` Peter Zijlstra
2020-02-27 15:50           ` Douglas Raillard
2020-01-27 17:16 ` Vincent Guittot
2020-02-10 11: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=5d732dc1-d343-24d2-bda9-072021a510ed@arm.com \
    --to=douglas.raillard@arm.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=qperret@google.com \
    --cc=rjw@rjwysocki.net \
    --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;
as well as URLs for NNTP newsgroup(s).