On 24/11/16 12:26, Vincent Guittot wrote:
Le Thursday 24 Nov 2016 à 11:01:50 (+0000), Juri Lelli a écrit :
On 24/11/16 11:54, Vincent Guittot wrote:
On 24 November 2016 at 11:32, Juri Lelli juri.lelli@arm.com wrote:
[...]
@@ -311,6 +311,8 @@ static int run_event(event_data_t *event, int dry_run,
rdata->res.timer.t_next = timespec_add(&rdata->res.timer.t_next, &t_period); clock_gettime(CLOCK_MONOTONIC, &t_now);
t_slack = timespec_sub(&rdata->res.timer.t_next, &t_now);*slack += timespec_to_usec_long(&t_slack);As said in previous patch, i think that you have mixed wake up latency and slack According to the description in patch 14 : slack: for periodic phases (phases that ends with a timer), time between the end of last event and the end of the phase, e.g
you should have *slack = timespec_to_usec_long(&t_slack);
I agree on the wu_lat (will fix the corresponding patch).
On the slack we probably didn't finish the discussion started on v2. I'm summing up beacuse we can have multiple timer events in the same phase, and though that sum up intermediate slacks is a sensible thing to do. What you think? (if we go this direction I'll of course update the description in patch 14).
So my original understanding of slack was that you want to get the "margin" or " real idle" time in a phase which means that we are interested in summing the slack values of the different timers of a phase (1st example below) Then, we started to discuss the use of slack as a margin to be compared with the deadline of a deadline task and in this case only the slack of the last timer is relevant (2nd example).
If I take an example similar to the one in patch 14
your current proposal is doing this taskA ...|-- run5 --|- timer7 -|-- run5--|..timer13.|-- run5 --|- timer7 -|-- run6 --|.timer13..| <--------------- period 20 --------------> <--------------- period 20 ---------------> <-slack2-> <+slack5-> <-slack2-> <+slack4->
so slack will be +7 and then +6
And from a deadline point of view only the last slack of the period is interesting taskA ...|-- run5 --|- timer7 -|-- run5--|..timer13.|-- run5 --|- timer7 -|-- run6 --|.timer13..| <--------------- period 20 --------------> <--------------- period 20 ---------------> <-slack5-> <-slack4->
Humm, to be honest, both make sense to me and might be useful. :)
Patrick is proposing that we add another property to timer events
"slack" : "[cumulative|last]"
What you think?