Messages in this thread | | | Date | Tue, 11 Apr 2017 10:53:05 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH v2] sched/fair: update scale invariance of PELT |
| |
On Tue, Apr 11, 2017 at 09:52:21AM +0200, Vincent Guittot wrote: > Le Monday 10 Apr 2017 à 19:38:02 (+0200), Peter Zijlstra a écrit : > > > > Thanks for the rebase. > > > > On Mon, Apr 10, 2017 at 11:18:29AM +0200, Vincent Guittot wrote: > > > > Ok, so let me try and paraphrase what this patch does. > > > > So consider a task that runs 16 out of our 32ms window: > > > > running idle > > |---------|---------| > > > > > > You're saying that when we scale running with the frequency, suppose we > > were at 50% freq, we'll end up with: > > > > run idle > > |----|---------| > > > > > > Which is obviously a shorter total then before; so what you do is add > > back the lost idle time like: > > > > run lost idle > > |----|----|---------| > > > > > > to arrive at the same total time. Which seems to make sense. > > Yes
OK, bear with me.
So we have:
util_sum' = utilsum * y^p +
p-1 d1 * y^p + 1024 * \Sum y^n + d3 * y^0 n=1
For the unscaled version, right?
Now for the scaled version, instead of adding a full 'd1,d2,d3' running segments, we want to add partially running segments, where r=f*d/f_max, and lost segments l=d-r to fill out the idle time.
But afaict we then end up with (F=f/f_max):
util_sum' = utilsum * y^p +
p-1 F * d1 * y^p + F * 1024 * \Sum y^n + F * d3 * y^0 n=1
And we can collect the common term F:
util_sum' = utilsum * y^p +
p-1 F * (d1 * y^p + 1024 * \Sum y^n + d3 * y^0) n=1
Which is exactly what we already did.
So now I'm confused. Where did I go wrong?
Because by scaling the contribution we get the exact result of doing the smaller 'running' + 'lost' segments.
| |