Messages in this thread | | | Date | Tue, 5 Jun 2018 17:54:31 +0100 | From | Patrick Bellasi <> | Subject | Re: [PATCH 2/2] sched/fair: util_est: add running_sum tracking |
| |
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
| |