On 24 November 2016 at 16:41, Juri Lelli juri.lelli@arm.com wrote:
On 24/11/16 12:39, Vincent Guittot wrote:
On 24 November 2016 at 12:36, Juri Lelli juri.lelli@arm.com wrote:
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?
yes, that's probably a good solution. So this will be a new parameters of the global object ?
No, I was actually thinking we put it in timer events.
"timer0" : { "ref" : "unique", "period" : 20000, "slack" : "cumulative" },
the default being "last"?
That could be a solution. What worried me a bit with this solution is that we start to put a metric parameter in the description of an event. This parameters will not affect the event only the log. Do we need to have this granularity ? Can't we start with a use case wide slack parameter and we can move it per phase or per event later if we see an interest like we have done for others parameters that were per task at the beg and then have become per phase ?