Re: [PATCH 2/2] sched/fair: util_est: add running_sum tracking

From: Patrick Bellasi
Date: Tue Jun 05 2018 - 12:54:44 EST


On 05-Jun 17:31, Juri Lelli wrote:
> On 05/06/18 16:11, Patrick Bellasi wrote:
>
> [...]
>
> > If I run an experiment with your example above, while using the
> > performance governor to rule out any possible scale invariance
> > difference, here is what I measure:
> >
> > Task1 (40ms delayed by the following Task2):
> > mean std max
> > running_avg 455.387449 22.940168 492.0
> > util_avg 433.233288 17.395477 458.0
> >
> > Task2 (waking up at same time of Task1 and running before):
> > mean std max
> > running_avg 430.281834 22.405175 455.0
> > util_avg 421.745331 22.098873 456.0
> >
> > and if I compare Task1 above with another experiment where Task1 is
> > running alone:
> >
> > Task1 (running alone):
> > mean std min
> > running_avg 460.257895 22.103704 460.0
> > util_avg 435.119737 17.647556 461.0
>
> Wait, why again in this last case running_avg != util_avg? :)

I _think_ it's mostly due to the rouding errors we have because of the
reasons I've explained in the reply to Joel:

https://lkml.org/lkml/2018/6/5/559
20180605152156.GD32302@e110439-lin

at the end, while commenting about the division overhead.

I should try the above examples while tracking the full signal at
___update_load_avg() time.

--
#include <best/regards.h>

Patrick Bellasi