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"?
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 ?
On 24/11/16 17:04, Vincent Guittot wrote:
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 ?
Fair enough. I'll put it the global section. :)
On 24/11/16 16:29, Juri Lelli wrote:
On 24/11/16 17:04, Vincent Guittot wrote:
[...]
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 ?
Fair enough. I'll put it the global section. :)
Does this looks OK to you?
--->8---
From 629ef6853ed55c6c09bb7add59c8d772a7535a23 Mon Sep 17 00:00:00 2001
From: Juri Lelli juri.lelli@arm.com Date: Thu, 24 Nov 2016 16:59:10 +0000 Subject: [PATCH] rt-app: introduce cumulative_slack global option
It might be useful, for phases that contains multiple timer events, to accumulate intermediate slack and report this number once the phase completes. Implement such behaviour and introduce a global option to select between current behaivour and the new one.
Signed-off-by: Juri Lelli juri.lelli@arm.com --- doc/tutorial.txt | 15 ++++++++++++--- src/rt-app.c | 5 ++++- src/rt-app_parse_config.c | 2 ++ src/rt-app_types.h | 2 ++ 4 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/doc/tutorial.txt b/doc/tutorial.txt index a4455b601cd3..54488a001381 100644 --- a/doc/tutorial.txt +++ b/doc/tutorial.txt @@ -137,6 +137,10 @@ Default value is "/dev/null". used to create IO-bounded and memory-bounded busy loop. Default value is 4194304(4MB).
+* cumulative_slack : Boolean. Accumulate slack (see below) measured during + successive timer events in a phase. Default value is False (time between the + end of last event and the end of the phase). + *** default global object: "global" : { "duration" : -1, @@ -150,7 +154,8 @@ used to create IO-bounded and memory-bounded busy loop. Default value is "ftrace" : false, "gnuplot" : false, "io_device" : "/dev/null" - "mem_buffer_size" : 4194304 + "mem_buffer_size" : 4194304, + "cumulative_slack" : false }
**** tasks object **** @@ -499,8 +504,8 @@ metrics are: - start/end : absolute start and end time of a phase. Same time base is used in ftrace - rel_st: start time of a phase relatively to the beg of the use case -- 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. +- slack: if global option "cumulative_slack" (see above) is false, time between + the end of last event and the end of the phase, e.g.
taskA ...|-- run5 --|- sleep5 -|-- run5--|..timer20.|-- run5 --|- sleep5 -|-- run6 --|.timer20.| <--------------- period 20 --------------> <--------------- period 20 --------------> @@ -513,6 +518,10 @@ metrics are: <--------------- period 20 --------------> <slack-5>
+ if global option "cumulative_slack" is true, all the intermediate slacks of a + phase with multiple timers are accumulated and reported when the phase + completes + - c_duration: sum of the configured duration of run/runtime events - c_period: sum of the timer(s) period(s) - wu_lat: sum of wakeup latencies after timer events diff --git a/src/rt-app.c b/src/rt-app.c index fb4b37d6ff7d..a7a1eb4a27fc 100644 --- a/src/rt-app.c +++ b/src/rt-app.c @@ -332,7 +332,10 @@ 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); - ldata->slack = timespec_to_usec_long(&t_slack); + if (opts.cumulative_slack) + ldata->slack += timespec_to_usec_long(&t_slack); + else + ldata->slack = timespec_to_usec_long(&t_slack); if (timespec_lower(&t_now, &rdata->res.timer.t_next)) { clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &rdata->res.timer.t_next, NULL); clock_gettime(CLOCK_MONOTONIC, &t_now); diff --git a/src/rt-app_parse_config.c b/src/rt-app_parse_config.c index fbc4612b2257..2b27f64f944a 100644 --- a/src/rt-app_parse_config.c +++ b/src/rt-app_parse_config.c @@ -784,6 +784,7 @@ parse_global(struct json_object *global, rtapp_options_t *opts) opts->pi_enabled = 0; opts->io_device = strdup("/dev/null"); opts->mem_buffer_size = DEFAULT_MEM_BUF_SIZE; + opts->cumulative_slack = 0; return; }
@@ -872,6 +873,7 @@ parse_global(struct json_object *global, rtapp_options_t *opts) "/dev/null"); opts->mem_buffer_size = get_int_value_from(global, "mem_buffer_size", TRUE, DEFAULT_MEM_BUF_SIZE); + opts->cumulative_slack = get_bool_value_from(global, "cumulative_slack", TRUE, 0);
}
diff --git a/src/rt-app_types.h b/src/rt-app_types.h index 718ce7798cc2..1eb9467fc03e 100644 --- a/src/rt-app_types.h +++ b/src/rt-app_types.h @@ -196,6 +196,8 @@ typedef struct _rtapp_options_t { int die_on_dmiss; int mem_buffer_size; char *io_device; + + int cumulative_slack; } rtapp_options_t;
typedef struct _timing_point_t {
On 24 November 2016 at 18:06, Juri Lelli juri.lelli@arm.com wrote:
On 24/11/16 16:29, Juri Lelli wrote:
On 24/11/16 17:04, Vincent Guittot wrote:
[...]
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 ?
Fair enough. I'll put it the global section. :)
Does this looks OK to you?
Yes looks good to me
--->8--- From 629ef6853ed55c6c09bb7add59c8d772a7535a23 Mon Sep 17 00:00:00 2001 From: Juri Lelli juri.lelli@arm.com Date: Thu, 24 Nov 2016 16:59:10 +0000 Subject: [PATCH] rt-app: introduce cumulative_slack global option
It might be useful, for phases that contains multiple timer events, to accumulate intermediate slack and report this number once the phase completes. Implement such behaviour and introduce a global option to select between current behaivour and the new one.
Signed-off-by: Juri Lelli juri.lelli@arm.com
doc/tutorial.txt | 15 ++++++++++++--- src/rt-app.c | 5 ++++- src/rt-app_parse_config.c | 2 ++ src/rt-app_types.h | 2 ++ 4 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/doc/tutorial.txt b/doc/tutorial.txt index a4455b601cd3..54488a001381 100644 --- a/doc/tutorial.txt +++ b/doc/tutorial.txt @@ -137,6 +137,10 @@ Default value is "/dev/null". used to create IO-bounded and memory-bounded busy loop. Default value is 4194304(4MB).
+* cumulative_slack : Boolean. Accumulate slack (see below) measured during
- successive timer events in a phase. Default value is False (time between the
- end of last event and the end of the phase).
*** default global object: "global" : { "duration" : -1, @@ -150,7 +154,8 @@ used to create IO-bounded and memory-bounded busy loop. Default value is "ftrace" : false, "gnuplot" : false, "io_device" : "/dev/null"
"mem_buffer_size" : 4194304
"mem_buffer_size" : 4194304,"cumulative_slack" : false }**** tasks object **** @@ -499,8 +504,8 @@ metrics are:
- start/end : absolute start and end time of a phase. Same time base is used in ftrace
- rel_st: start time of a phase relatively to the beg of the use case
-- 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.
+- slack: if global option "cumulative_slack" (see above) is false, time between
the end of last event and the end of the phase, e.g.
taskA ...|-- run5 --|- sleep5 -|-- run5--|..timer20.|-- run5 --|- sleep5 -|-- run6 --|.timer20.| <--------------- period 20 --------------> <--------------- period 20 -------------->
@@ -513,6 +518,10 @@ metrics are: <--------------- period 20 --------------> <slack-5>
- if global option "cumulative_slack" is true, all the intermediate slacks of a
- phase with multiple timers are accumulated and reported when the phase
- completes
- c_duration: sum of the configured duration of run/runtime events
- c_period: sum of the timer(s) period(s)
- wu_lat: sum of wakeup latencies after timer events
diff --git a/src/rt-app.c b/src/rt-app.c index fb4b37d6ff7d..a7a1eb4a27fc 100644 --- a/src/rt-app.c +++ b/src/rt-app.c @@ -332,7 +332,10 @@ 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);
ldata->slack = timespec_to_usec_long(&t_slack);
if (opts.cumulative_slack)ldata->slack += timespec_to_usec_long(&t_slack);elseldata->slack = timespec_to_usec_long(&t_slack); if (timespec_lower(&t_now, &rdata->res.timer.t_next)) { clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &rdata->res.timer.t_next, NULL); clock_gettime(CLOCK_MONOTONIC, &t_now);diff --git a/src/rt-app_parse_config.c b/src/rt-app_parse_config.c index fbc4612b2257..2b27f64f944a 100644 --- a/src/rt-app_parse_config.c +++ b/src/rt-app_parse_config.c @@ -784,6 +784,7 @@ parse_global(struct json_object *global, rtapp_options_t *opts) opts->pi_enabled = 0; opts->io_device = strdup("/dev/null"); opts->mem_buffer_size = DEFAULT_MEM_BUF_SIZE;
opts->cumulative_slack = 0; return; }@@ -872,6 +873,7 @@ parse_global(struct json_object *global, rtapp_options_t *opts) "/dev/null"); opts->mem_buffer_size = get_int_value_from(global, "mem_buffer_size", TRUE, DEFAULT_MEM_BUF_SIZE);
opts->cumulative_slack = get_bool_value_from(global, "cumulative_slack", TRUE, 0);}
diff --git a/src/rt-app_types.h b/src/rt-app_types.h index 718ce7798cc2..1eb9467fc03e 100644 --- a/src/rt-app_types.h +++ b/src/rt-app_types.h @@ -196,6 +196,8 @@ typedef struct _rtapp_options_t { int die_on_dmiss; int mem_buffer_size; char *io_device;
int cumulative_slack;} rtapp_options_t;
typedef struct _timing_point_t {
2.10.0
On 24/11/16 18:24, Vincent Guittot wrote:
On 24 November 2016 at 18:06, Juri Lelli juri.lelli@arm.com wrote:
On 24/11/16 16:29, Juri Lelli wrote:
On 24/11/16 17:04, Vincent Guittot wrote:
[...]
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 ?
Fair enough. I'll put it the global section. :)
Does this looks OK to you?
Yes looks good to me
OK, I've put what below on top of the stack. Can I take your "LGTM" as an ack? :)
--->8--- From 629ef6853ed55c6c09bb7add59c8d772a7535a23 Mon Sep 17 00:00:00 2001 From: Juri Lelli juri.lelli@arm.com Date: Thu, 24 Nov 2016 16:59:10 +0000 Subject: [PATCH] rt-app: introduce cumulative_slack global option
It might be useful, for phases that contains multiple timer events, to accumulate intermediate slack and report this number once the phase completes. Implement such behaviour and introduce a global option to select between current behaivour and the new one.
Signed-off-by: Juri Lelli juri.lelli@arm.com
doc/tutorial.txt | 15 ++++++++++++--- src/rt-app.c | 5 ++++- src/rt-app_parse_config.c | 2 ++ src/rt-app_types.h | 2 ++ 4 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/doc/tutorial.txt b/doc/tutorial.txt index a4455b601cd3..54488a001381 100644 --- a/doc/tutorial.txt +++ b/doc/tutorial.txt @@ -137,6 +137,10 @@ Default value is "/dev/null". used to create IO-bounded and memory-bounded busy loop. Default value is 4194304(4MB).
+* cumulative_slack : Boolean. Accumulate slack (see below) measured during
- successive timer events in a phase. Default value is False (time between the
- end of last event and the end of the phase).
*** default global object: "global" : { "duration" : -1, @@ -150,7 +154,8 @@ used to create IO-bounded and memory-bounded busy loop. Default value is "ftrace" : false, "gnuplot" : false, "io_device" : "/dev/null"
"mem_buffer_size" : 4194304
"mem_buffer_size" : 4194304,"cumulative_slack" : false }**** tasks object **** @@ -499,8 +504,8 @@ metrics are:
- start/end : absolute start and end time of a phase. Same time base is used in ftrace
- rel_st: start time of a phase relatively to the beg of the use case
-- 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.
+- slack: if global option "cumulative_slack" (see above) is false, time between
the end of last event and the end of the phase, e.g.
taskA ...|-- run5 --|- sleep5 -|-- run5--|..timer20.|-- run5 --|- sleep5 -|-- run6 --|.timer20.| <--------------- period 20 --------------> <--------------- period 20 -------------->
@@ -513,6 +518,10 @@ metrics are: <--------------- period 20 --------------> <slack-5>
- if global option "cumulative_slack" is true, all the intermediate slacks of a
- phase with multiple timers are accumulated and reported when the phase
- completes
- c_duration: sum of the configured duration of run/runtime events
- c_period: sum of the timer(s) period(s)
- wu_lat: sum of wakeup latencies after timer events
diff --git a/src/rt-app.c b/src/rt-app.c index fb4b37d6ff7d..a7a1eb4a27fc 100644 --- a/src/rt-app.c +++ b/src/rt-app.c @@ -332,7 +332,10 @@ 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);
ldata->slack = timespec_to_usec_long(&t_slack);
if (opts.cumulative_slack)ldata->slack += timespec_to_usec_long(&t_slack);elseldata->slack = timespec_to_usec_long(&t_slack); if (timespec_lower(&t_now, &rdata->res.timer.t_next)) { clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &rdata->res.timer.t_next, NULL); clock_gettime(CLOCK_MONOTONIC, &t_now);diff --git a/src/rt-app_parse_config.c b/src/rt-app_parse_config.c index fbc4612b2257..2b27f64f944a 100644 --- a/src/rt-app_parse_config.c +++ b/src/rt-app_parse_config.c @@ -784,6 +784,7 @@ parse_global(struct json_object *global, rtapp_options_t *opts) opts->pi_enabled = 0; opts->io_device = strdup("/dev/null"); opts->mem_buffer_size = DEFAULT_MEM_BUF_SIZE;
opts->cumulative_slack = 0; return; }@@ -872,6 +873,7 @@ parse_global(struct json_object *global, rtapp_options_t *opts) "/dev/null"); opts->mem_buffer_size = get_int_value_from(global, "mem_buffer_size", TRUE, DEFAULT_MEM_BUF_SIZE);
opts->cumulative_slack = get_bool_value_from(global, "cumulative_slack", TRUE, 0);}
diff --git a/src/rt-app_types.h b/src/rt-app_types.h index 718ce7798cc2..1eb9467fc03e 100644 --- a/src/rt-app_types.h +++ b/src/rt-app_types.h @@ -196,6 +196,8 @@ typedef struct _rtapp_options_t { int die_on_dmiss; int mem_buffer_size; char *io_device;
int cumulative_slack;} rtapp_options_t;
typedef struct _timing_point_t {
2.10.0
Le 24 nov. 2016 7:17 PM, "Juri Lelli" juri.lelli@arm.com a écrit :
On 24/11/16 18:24, Vincent Guittot wrote:
On 24 November 2016 at 18:06, Juri Lelli juri.lelli@arm.com wrote:
On 24/11/16 16:29, Juri Lelli wrote:
On 24/11/16 17:04, Vincent Guittot wrote:
[...]
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 ?
Fair enough. I'll put it the global section. :)
Does this looks OK to you?
Yes looks good to me
OK, I've put what below on top of the stack. Can I take your "LGTM" as an ack? :)
Yes
--->8--- From 629ef6853ed55c6c09bb7add59c8d772a7535a23 Mon Sep 17 00:00:00 2001 From: Juri Lelli juri.lelli@arm.com Date: Thu, 24 Nov 2016 16:59:10 +0000 Subject: [PATCH] rt-app: introduce cumulative_slack global option
It might be useful, for phases that contains multiple timer events, to accumulate intermediate slack and report this number once the phase completes. Implement such behaviour and introduce a global option to select between current behaivour and the new one.
Signed-off-by: Juri Lelli juri.lelli@arm.com
doc/tutorial.txt | 15 ++++++++++++--- src/rt-app.c | 5 ++++- src/rt-app_parse_config.c | 2 ++ src/rt-app_types.h | 2 ++ 4 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/doc/tutorial.txt b/doc/tutorial.txt index a4455b601cd3..54488a001381 100644 --- a/doc/tutorial.txt +++ b/doc/tutorial.txt @@ -137,6 +137,10 @@ Default value is "/dev/null". used to create IO-bounded and memory-bounded busy loop. Default
value is
4194304(4MB).
+* cumulative_slack : Boolean. Accumulate slack (see below) measured
during
- successive timer events in a phase. Default value is False (time
between the
- end of last event and the end of the phase).
*** default global object: "global" : { "duration" : -1, @@ -150,7 +154,8 @@ used to create IO-bounded and memory-bounded busy
loop. Default value is
"ftrace" : false, "gnuplot" : false, "io_device" : "/dev/null"
"mem_buffer_size" : 4194304
"mem_buffer_size" : 4194304,"cumulative_slack" : false }**** tasks object **** @@ -499,8 +504,8 @@ metrics are:
- start/end : absolute start and end time of a phase. Same time base
is used in
ftrace
- rel_st: start time of a phase relatively to the beg of the use case
-- 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.
+- slack: if global option "cumulative_slack" (see above) is false,
time between
the end of last event and the end of the phase, e.g.
taskA ...|-- run5 --|- sleep5 -|-- run5--|..timer20.|-- run5 --|-
sleep5 -|-- run6 --|.timer20.|
<--------------- period 20 -------------->
<--------------- period 20 -------------->
@@ -513,6 +518,10 @@ metrics are: <--------------- period 20 --------------> <slack-5>
- if global option "cumulative_slack" is true, all the intermediate
slacks of a
- phase with multiple timers are accumulated and reported when the
phase
- completes
- c_duration: sum of the configured duration of run/runtime events
- c_period: sum of the timer(s) period(s)
- wu_lat: sum of wakeup latencies after timer events
diff --git a/src/rt-app.c b/src/rt-app.c index fb4b37d6ff7d..a7a1eb4a27fc 100644 --- a/src/rt-app.c +++ b/src/rt-app.c @@ -332,7 +332,10 @@ 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);
ldata->slack =
timespec_to_usec_long(&t_slack);
if (opts.cumulative_slack)ldata->slack +=
timespec_to_usec_long(&t_slack);
elseldata->slack =
timespec_to_usec_long(&t_slack);
if (timespec_lower(&t_now,
&rdata->res.timer.t_next)) {
clock_nanosleep(CLOCK_MONOTONIC,
TIMER_ABSTIME, &rdata->res.timer.t_next, NULL);
clock_gettime(CLOCK_MONOTONIC,
&t_now);
diff --git a/src/rt-app_parse_config.c b/src/rt-app_parse_config.c index fbc4612b2257..2b27f64f944a 100644 --- a/src/rt-app_parse_config.c +++ b/src/rt-app_parse_config.c @@ -784,6 +784,7 @@ parse_global(struct json_object *global,
rtapp_options_t *opts)
opts->pi_enabled = 0; opts->io_device = strdup("/dev/null"); opts->mem_buffer_size = DEFAULT_MEM_BUF_SIZE;
opts->cumulative_slack = 0; return; }@@ -872,6 +873,7 @@ parse_global(struct json_object *global,
rtapp_options_t *opts)
"/dev/null"); opts->mem_buffer_size = get_int_value_from(global,
"mem_buffer_size",
TRUE,
DEFAULT_MEM_BUF_SIZE);
opts->cumulative_slack = get_bool_value_from(global,
"cumulative_slack", TRUE, 0);
}
diff --git a/src/rt-app_types.h b/src/rt-app_types.h index 718ce7798cc2..1eb9467fc03e 100644 --- a/src/rt-app_types.h +++ b/src/rt-app_types.h @@ -196,6 +196,8 @@ typedef struct _rtapp_options_t { int die_on_dmiss; int mem_buffer_size; char *io_device;
int cumulative_slack;} rtapp_options_t;
typedef struct _timing_point_t {
2.10.0
-
Juri Lelli -
Vincent Guittot