On 22/11/16 14:17, Vincent Guittot wrote:
On 22 November 2016 at 12:00, Juri Lelli juri.lelli@arm.com wrote:
On 22/11/16 11:50, Vincent Guittot wrote:
On 22 November 2016 at 11:41, Juri Lelli juri.lelli@arm.com wrote:
On 22/11/16 10:21, Juri Lelli wrote:
On 22/11/16 10:41, Vincent Guittot wrote:
[...]
There also the c_run metrics in another patch, does it mean that you want only one run event per phase ?
Nope. That is broken in my current set. I'll fix that as you suggested (summing up the durations).
Which basically should result in the following right?
--->8--- src/rt-app.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/rt-app.c b/src/rt-app.c index 655c43e06a7d..bec511121d77 100644 --- a/src/rt-app.c +++ b/src/rt-app.c @@ -287,7 +287,7 @@ static int run_event(event_data_t *event, int dry_run, { struct timespec t_start, t_end; log_debug("run %d ", event->duration);
ldata->c_run = event->duration;
ldata->c_run += event->duration; clock_gettime(CLOCK_MONOTONIC, &t_start); *perf += loadwait(event->duration); clock_gettime(CLOCK_MONOTONIC, &t_end);--->8---
I was actually thinking that we should also sum up durations of all event that specify a duration (sleep, runtime, etc.) and maybe modify the log header as s/c_run/c_duration/ ?
IMO adding runtime makes perfectly sense as commented in the related patch But not sleep which is a idle state just like timer
True.. but I was thinking that the best case slack will be affected also by sleep phases, so then if we compared the measured slack with the best one we should probably account for sleep events ?
e.g.,
|--- run 5000 ---|-- sleep 4000 --|--- run 5000 ---| |-----------------------------period 20000 -------------------| |----------| measured slack 6000
If we factor sleep duration in, we will compare 6000 (best case) vs 6000. If we don't, we will compare 10000 (best case) vs 6000, which ends up telling us that we ran slower for some reason, while instead we simply slept by constrution?
IIUC the slack metric represents the real "idle/sleep" time compared to what have been configured (timer duration minus duration of events in the time slot) Can't we also add a slack value for sleep events and add it slack value of timers in a phase to stay consistent with other metrics ?
so in the example above, the sack time will be 4000+6000 like the best case
Mmm, too me the slack it the time left before the next activation (of a periodic task) after all the events of the current activation have been completed. So, I'd say that we actually want to report 6000 in the example above. 'sleep' event is still something that we want to accomplish inside the current period, right? So it's like a 'runtime' (the freq invariant version of 'run').