On 21/11/16 15:08, Vincent Guittot wrote:
Le Monday 21 Nov 2016 à 12:26:03 (+0000), Juri Lelli a écrit :
On 21/11/16 10:33, Vincent Guittot wrote:
On 21 November 2016 at 10:28, Vincent Guittot vincent.guittot@linaro.org wrote:
On 17 November 2016 at 17:34, Juri Lelli juri.lelli@arm.com wrote:
[...]
case rtapp_timer: {
struct timespec t_period, t_now;
struct timespec t_period, t_now, t_wu; log_debug("timer %d ", event->duration); t_period = usec_to_timespec(event->duration);@@ -311,10 +311,15 @@ 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);
if (timespec_lower(&t_now, &rdata->res.timer.t_next))
if (timespec_lower(&t_now, &rdata->res.timer.t_next)) { clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &rdata->res.timer.t_next, NULL);
else
clock_gettime(CLOCK_MONOTONIC, &t_now);t_wu = timespec_sub(&t_now, &rdata->res.timer.t_next);*wu_latency = timespec_to_usec(&t_wu);You should add the same wake up latency metric for the sleep event
OK, will look into it.
} else { clock_gettime(CLOCK_MONOTONIC, &rdata->res.timer.t_next);*wu_latency = 0UL;} } break;[...]
@@ -608,6 +616,7 @@ void *thread_body(void *arg) curr_timing->period = timespec_to_usec(&t_diff); curr_timing->duration = duration; curr_timing->perf = perf;
curr_timing->wu_latency = wu_latency;What happen if we have several timer in one phase ? we will only get the last wake up latency, isn't it ?
Not sure I get where the problem is. Can you give me an example (and intended usage) of a phase with multiple timers? I don't seem to understand how that is supposed to work. :)
Below is an example of a timer that is used twice in the same phase: "tasks" : { "thread0" : { "instance" : 1, "loop" : -1, "run0" : 10000, "timer0" : { "ref" : "timerA", "period" : 20000 }, "run1" : 20000, "timer1" : { "ref" : "timerA", "period" : 40000 }, } },
Mmm, but these are IMHO two distinct phases and we should describe them as such (maybe add a check to disallow such a json description). It seems that we only make confusion descriptions possible (and we complicate handling from a code pow).
More generally speaking, the log timing are saved per phase so the associated metrics should be per phase as well. With the example above, the fields c_period and the c_run give the last part of the phase.
Then, if we also record the wake up latency of sleep event, there are even more use case where several sleep and timer are used in a phase