On 23 November 2016 at 09:29, Juri Lelli juri.lelli@arm.com wrote:
On 22/11/16 17:53, Vincent Guittot wrote:
On 22 November 2016 at 14:53, Juri Lelli juri.lelli@arm.com wrote:
On 22/11/16 14:17, Vincent Guittot wrote:
On 22 November 2016 at 12:00, Juri Lelli juri.lelli@arm.com wrote:
[...]
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').
ok so I'm not sure to understand what you want to measure with slack. Your description sounds like something that you want to compare to a deadline task properties
If the deadline corresponds to the period the definition matches yes. I think for periodic tasks it is usually the case, right? If deadline == period, the slack gives us an indication about how close to the deadline an activation completed its work.
Your patchset changes the log file to the following: #idx: just an increasing index of the phase perf: number of busy loop that has been executed in the phase run: duration used to execute the run/runtime events period: duration of the phase start: absolute start time end: absolute end time rel_st: relative start time of the phase slack: time between end of the last event and the end of the phase ?
If the phase is periodic yes (see the example above). I can add such example in the documentation together with the patch introducing the new column.
yes. it would be good to update the documentation to explain what the new metrics are
c_run: sum of configured run/runtime duration c_period: sum of the timer period ?
Yeah, I guess we can go with summing the periods.
wu_lat: sum of wakeup latency ?
Huh, yep. I guess we can add up wu_lat(s) experienced during a phase (multiple timers).