`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 theclarification. It is a good point.Taking into consideration the dynamic, in the case #1, the break even isnot reached, the idle duration is smaller and that leads the governor tochoose shallower idle states after and consequently CPU0 will be used inpriority. 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 thegovernor should be keeping choosing the same idle state.I don't know what is more energy/perf efficient. IMO this is veryworkload dependent. The only way to check is to test. Hopefully I canfind a platform for that.--  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCsFollow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |<http://twitter.com/#!/linaroorg> Twitter |<http://www.linaro.org/linaro-blog/> Blog`