On June 19, 2018 6:16:20 AM PDT, Qais Yousef qais.yousef.arm@gmail.com wrote:
On Thu, Jun 14, 2018 at 10:26 AM, Patrick Bellasi patrick.bellasi@arm.com wrote:
[...]
I _think_ this proposal has (at least) the same issue of my previous one: it inflates tasks utilization by freezing (i.e. ignoring) preemption time and thus reducing by consequence the task periods.
Vincent come up with a really good exaplaination here: 20180606103809.GG31675@e110439-lin https://lkml.org/lkml/2018/6/6/256
Can you please better check if the above reasoning / explaination matches your proposal too?
I am a newbie in here, so apologies in advance if my question is silly or doesn't make any sense.
Why can't we introduce a new 'milder' decay function for this case?
For example
Task 1 state RRRRSSSSSSERRRRSSSSSSERRRRSSSSSS util_avg AAAADDDDDD AAAADDDDDD AAAADDDDDD
Task 2 state WWWWRRRRSSEWWWWRRRRSSEWWWWRRRRSS util_avg DDDDAAAADD DDDDAAAADD DDDDAAAADD running_avg AAAADDC AAAADDC AAAADD
We can have the
running_avg ddddAAAADDC [.....]
Where d is a different decay function than D. d can be defined such that y^32 is 0.75 for instance, so we decay at a slower rate. Or it can be non linear and decay at faster rate as time passes
I don't think so... The problem is not about the rate of decay but about decaying vs not decaying. Vincent's example proves that you have to decay when CFS task is not running (whether preempted or sleeping)
J.
e.g
- For d[t < 8ms] y^32 = 0.7S
- For d[t < 16ms] y^32 = 0.6S
- For d[t >= 32ms] y^32 = 0.5S
Where S is the last signal value before preemption.
We can also introduce a new A function, a, such that it boosts the signal for the N ticks the task was preempted for
a[n] = x[n]S
Where
x[n] = 1 for n >= N x[n] = 1.25 (for example) for 0 =< n < N.
If this makes sense and not total BS, I suspect *only* boosting the accumulated signal after preemption will have less knock on effect on the rest of the system. IOW, better leave the D function intact/coherent.
running_avg DDDDaaaaDDC [.....]
Thanks
-- Qais Yousef