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
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