Re: [PATCH v5 09/14] sched: Add over-utilization/tipping point indicator

From: Dietmar Eggemann
Date: Mon Aug 06 2018 - 09:20:37 EST


On 08/06/2018 02:37 PM, Vincent Guittot wrote:
On Mon, 6 Aug 2018 at 14:29, Dietmar Eggemann <dietmar.eggemann@xxxxxxx> wrote:

On 08/06/2018 12:33 PM, Vincent Guittot wrote:
On Mon, 6 Aug 2018 at 12:08, Dietmar Eggemann <dietmar.eggemann@xxxxxxx> wrote:

On 08/06/2018 10:40 AM, Vincent Guittot wrote:
On Fri, 3 Aug 2018 at 17:55, Quentin Perret <quentin.perret@xxxxxxx> wrote:

On Friday 03 Aug 2018 at 15:49:24 (+0200), Vincent Guittot wrote:
On Fri, 3 Aug 2018 at 10:18, Quentin Perret <quentin.perret@xxxxxxx> wrote:

On Friday 03 Aug 2018 at 09:48:47 (+0200), Vincent Guittot wrote:
On Thu, 2 Aug 2018 at 18:59, Quentin Perret <quentin.perret@xxxxxxx> wrote:

[...]

I think we're discussing two different things right now:
1. Should forkees go in find_energy_efficient_cpu() ?
2. Should forkees have 0 of initial util_avg when EAS is enabled ?

It's the same topic: How EAS should consider a newly created task ?

For now, we let the "performance" mode selects a CPU. This CPU will
most probably be worst CPU from a EAS pov because it's the idlest CPU
in the idlest group which is the opposite of what EAS tries to do

The current behavior is :
For every new task, the cpu selection is done assuming it's a heavy
task with the max possible load_avg, and it looks for the idlest cpu.
This means that if the system is lightly loaded, scheduler will select
most probably a idle big core.

AFAICS, task load doesn't seem to be used for find_idlest_cpu() (
find_idlest_group() and find_idlest_group_cpu()). So the forkee
(SD_BALANCE_FORK) is placed independently of his task load.

hmm ... so what is used if load or runnable load are not used ?
find_idlest_group() uses load and runnable load but skip spare
capacity in case of fork

Yes, runnable load and load are used, but from the cpus, not from the task.

yes that's right, I have skipped the "task" word when reading.
So scheduler looks for the idlest CPU taking into account only CPU
loads. Then the task load starts to highest value until it get a
chance to reduce and stabilize to its final value

This could potentially allow us to find a better init value for sa->[runnable]_load_avg. At least we could use the information of the initial task rq.



[...]