LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Morten Rasmussen <morten.rasmussen@arm.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ben Segall <bsegall@google.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Qais Yousef <qais.yousef@arm.com>,
	Valentin Schneider <valentin.schneider@arm.com>
Subject: Re: [PATCH V2] sched: fair: Use the earliest break even
Date: Wed, 18 Mar 2020 11:17:49 +0100	[thread overview]
Message-ID: <798e9bde-a207-3a0e-0f13-0e27d60fd286@linaro.org> (raw)
In-Reply-To: <20200318082452.GA6103@e123083-lin>

On 18/03/2020 09:24, Morten Rasmussen wrote:
> On Tue, Mar 17, 2020 at 06:07:43PM +0100, Daniel Lezcano wrote:
>> On 17/03/2020 15:30, Morten Rasmussen wrote:
>>> On Tue, Mar 17, 2020 at 02:48:51PM +0100, Daniel Lezcano wrote:
>>>> On 17/03/2020 08:56, Morten Rasmussen wrote:
>>>>> On Thu, Mar 12, 2020 at 11:04:19AM +0100, Daniel Lezcano wrote:
>>>>>>>> In order to be more energy efficient but without impacting the
>>>>>>>> performances, let's use another criteria: the break even deadline.
>>>>>>>>
>>>>>>>> At idle time, when we store the idle state the CPU is entering in, we
>>>>>>>> compute the next deadline where the CPU could be woken up without
>>>>>>>> spending more energy to sleep.
>>>>>
>>>>> I don't follow the argument that sleeping longer should improve energy
>>>>> consumption. 
>>>>
>>>> May be it is not explained correctly.
>>>>
>>>> The patch is about selecting a CPU with the smallest break even deadline
>>>> value. In a group of idle CPUs in the same idle state, we will pick the
>>>> one with the smallest break even dead line which is the one with the
>>>> highest probability it already reached its target residency.
>>>>
>>>> It is best effort.
>>>
>>> Indeed. I get what the patch does, I just don't see how the patch
>>> improves energy efficiency.
>>
>> If the CPU is woken up before it reached the break even, the idle state
>> cost in energy is greater than the energy it saved.
>>
>> Am I misunderstanding your point?
> 
> Considering just the waking then yes, it reaches energy break-even.
> However, considering all the CPUs in the system, it just moves the idle
> entry/exit energy cost to a different CPU, it doesn't go away.
> 
> Whether you have:
> 
>                |-BE-|
>            ____    ____
> CPU0:  ___/    \__/    \___
> 
> CPU1:  ____________________
> 
> Or:
>                |-BE-|
>            ____
> CPU0:  ___/    \___________
>                    ____
> CPU1:  ___________/    \___
> 
> _
>   = CPU busy = P_{busy}
> _ = CPU idle = P_{idle}
> / = CPU idle exit = P_{exit}
> \ = CPU idle entry = P_{entry}
> 
> The sum of areas under the curves is the same, i.e. the total energy is
> unchanged.

It is a counter-intuitive comment, now I get it, thanks for the
clarification. It is a good point.

Taking into consideration the dynamic, in the case #1, the break even is
not reached, the idle duration is smaller and that leads the governor to
choose shallower idle states after and consequently CPU0 will be used in
priority. We end up with CPU0 in a shallow state and CPU1 in a deep state.

With the case #2, we can have the CPUs in both deep state and the
governor should be keeping choosing the same idle state.

I don't know what is more energy/perf efficient. IMO this is very
workload dependent. The only way to check is to test. Hopefully I can
find a platform for that.


-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog


  reply	other threads:[~2020-03-18 10:17 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-11 20:26 Daniel Lezcano
2020-03-12  8:36 ` Vincent Guittot
2020-03-12 10:04   ` Daniel Lezcano
2020-03-12 12:27     ` Vincent Guittot
2020-03-13 12:15       ` Daniel Lezcano
2020-03-13 13:15         ` Vincent Guittot
2020-03-13 13:17           ` Daniel Lezcano
2020-03-13 13:21             ` Vincent Guittot
2020-03-17  7:56     ` Morten Rasmussen
2020-03-17 13:48       ` Daniel Lezcano
2020-03-17 14:30         ` Morten Rasmussen
2020-03-17 17:07           ` Daniel Lezcano
2020-03-18  8:24             ` Morten Rasmussen
2020-03-18 10:17               ` Daniel Lezcano [this message]
2020-03-18 14:38                 ` Morten Rasmussen
2020-03-18  7:51           ` Vincent Guittot
2020-03-18  8:33             ` Morten Rasmussen
2020-03-17 10:56 ` Valentin Schneider
2020-03-17 13:59   ` Daniel Lezcano

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=798e9bde-a207-3a0e-0f13-0e27d60fd286@linaro.org \
    --to=daniel.lezcano@linaro.org \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=morten.rasmussen@arm.com \
    --cc=peterz@infradead.org \
    --cc=qais.yousef@arm.com \
    --cc=rostedt@goodmis.org \
    --cc=valentin.schneider@arm.com \
    --cc=vincent.guittot@linaro.org \
    --subject='Re: [PATCH V2] sched: fair: Use the earliest break even' \
    /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

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).