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.
