Re: [PATCH v3 4/5] sched/pelt: Add a new runnable average signal

[Valentin Schneider]

I somehow lost track of that email, sorry for the delayed response.

On 2/21/20 8:56 AM, Vincent Guittot wrote:
> On Thu, 20 Feb 2020 at 17:11, Valentin Schneider
> <valentin.schneider@xxxxxxx> wrote:
>>
>> On 20/02/2020 14:36, Vincent Guittot wrote:
>>> I agree that setting by default to SCHED_CAPACITY_SCALE is too much
>>> for little core.
>>> The problem for little core can be fixed by using the cpu capacity instead
>>>
>>
>> So that's indeed better for big.LITTLE & co. Any reason however for not
>> aligning with the initialization of util_avg ?
> 
> The runnable_avg is the unweighted version of the load_avg so they
> should both be sync at init and SCHED_CAPACITY_SCALE is in fact the
> right value. Using cpu_scale is the same for smp and big core so we
> can use it instead.
> 
> Then, the initial value of util_avg has never reflected some kind of
> realistic value for the utilization of a new task, especially if those
> tasks will become big ones. Runnable_avg now balances this effect to
> say that we don't know what will be the behavior of the new task,
> which might end up using all spare capacity although current
> utilization is low and CPU is not "fully used".

I'd argue that the init values we pick for either runnable_avg or util_avg
are both equally bogus.

> In fact, this is
> exactly the purpose of runnable: highlight that there is maybe no
> spare capacity even if CPU's utilization is low because of external
> event like task migration or having new tasks with most probably wrong
> utilization.
> 
> That being said, there is a bigger problem with the current version of
> this patch, which is that I forgot to use runnable in
> update_sg_wakeup_stats(). I have a patch that fixes this problem.
> 
> Also, I have tested both proposals with hackbench on my octo cores and
> using cpu_scale gives slightly better results than util_avg, which
> probably reflects the case I mentioned above.
> 
> grp     cpu_scale            util_avg               improvement
> 1       1,191(+/-0.77 %)     1,204(+/-1.16 %)       -1.07 %
> 4       1,147(+/-1.14 %)     1,195(+/-0.52 %)       -4.21 %
> 8       1,112(+/-1,52 %)     1,124(+/-1,45 %)       -1.12 %
> 16      1,163(+/-1.72 %)     1,169(+/-1.58 %)       -0,45 %
> 

Interesting, thanks for providing the numbers. I'd be curious to figure out
where the difference really stems from, but in the meantime consider me
convinced ;)