Hi all,
this is an attempt to align and finally merge Linaro's and ARM's versions of
rt-app.
v3 should address Vincent's comments on v2 (by also adding a couple of patches,
the log header description one and the relative/absolute timers one).
Please comment and let me know if this new version of the set is OK for
merging.
Thanks a lot,
- Juri
[1] https://github.com/scheduler-tools/rt-app/commits/master
Juri Lelli (17):
doc: clarify example for config step
rt-app: fix compile warnings
rt-app: add a t_zero to which every tasks has to refer
rt-app: convert log header to fixed width spaces
rt-app: add wake-up latency to the log metrics
rt-app: add slack to log metrics
rt-app: fix batch tasks
rt-app: add 'configured period' to log metrics
rt-app: write logs only if continue_running is set
rt-app: refactor log data to reduce the number of parameters of run()
rt-app: move wu_lat to the end of the log
rt-app: make c_prd c_period and enlarge it
rt-app: add configured duration (c_duration) to log metrics
doc: add log header fields descriptions
rt-app: let caller manage tracing start/stop
rt-app: add delay thread property
rt-app: implement relative/absolute timers
doc/examples/cpufreq_governor_efficiency/dvfs.sh | 2 +-
doc/tutorial.txt | 128 +++++++++++++++++++--
libdl/dl_syscalls.h | 4 +-
src/rt-app.c | 137 ++++++++++++++++-------
src/rt-app_args.h | 3 -
src/rt-app_parse_config.c | 11 ++
src/rt-app_parse_config.h | 2 +
src/rt-app_types.h | 16 +++
src/rt-app_utils.c | 27 ++++-
src/rt-app_utils.h | 6 +
10 files changed, 278 insertions(+), 58 deletions(-)
--
2.10.0
On 24/11/16 12:39, Vincent Guittot wrote:
> On 24 November 2016 at 12:36, Juri Lelli <juri.lelli(a)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(a)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"?
Hi all,
this is an attempt to align and finally merge Linaro's and ARM's versions of
rt-app.
v2 should address Vincent's comments on v1, plus I added a patch about tracing
(13/14) that I thought need fixing while I was doing more debugging.
Please let me know if this new version of the set is OK for merging.
Thanks a lot,
- Juri
[1] https://github.com/scheduler-tools/rt-app/commits/master
Juri Lelli (14):
doc: clarify example for config step
rt-app: fix compile warnings
rt-app: add a t_zero to which every tasks has to refer
rt-app: add wake-up latency to the log metrics
rt-app: add slack to log metrics
rt-app: fix batch tasks
rt-app: add 'configured period' to log metrics
rt-app: write logs only if continue_running is set
rt-app: refactor log data to reduce the number of parameters of run()
rt-app: move wu_lat to the end of the log
rt-app: make c_prd c_period and enlarge it
rt-app: add configured run (c_run) to log metrics
rt-app: let caller manage tracing start/stop
rt-app: add delay thread property
doc/tutorial.txt | 28 +++++++++++
libdl/dl_syscalls.h | 4 +-
src/rt-app.c | 121 +++++++++++++++++++++++++++++++++++-----------
src/rt-app_args.h | 3 --
src/rt-app_parse_config.c | 5 ++
src/rt-app_parse_config.h | 2 +
src/rt-app_types.h | 15 ++++++
src/rt-app_utils.c | 27 +++++++++--
src/rt-app_utils.h | 6 +++
9 files changed, 175 insertions(+), 36 deletions(-)
--
2.10.0
Hi all,
this is an attempt to align and finally merge Linaro's and ARM's versions of
rt-app (so that we make the whole story more clean and sound and possibly
facilitate adoption by even more people). Apologies for not doing this before
and not being responsive to Vincent and Pi-Cheng previous attemps; turns out
that I never had really the time to seriously looking at this until now.
Anyway, I've already pushed Linaro's current tree on scheduler-tools/rt-app
master[1] (and added Vincent as co-maintainer); this series is based on top of
that. These patches represent the deltas between what we currently use (for EAS
evaluation and LISA tooling) and Linaro's version.
Please have a look and comment. I slightly tested them and couldn't find any
problems yet; please, do the same.
Thanks a lot,
- Juri
[1] https://github.com/scheduler-tools/rt-app/commits/master
Juri Lelli (13):
doc: clarify example for config step
rt-app: fix compile warnings
rt-app: add a t_zero to which every tasks has to refer
rt-app: add wake-up latency to the log metrics
rt-app: add slack to log metrics
rt-app: add 'delay' phase
rt-app: fix batch tasks
rt-app: add 'configured period' to log metrics
rt-app: write logs only if continue_running is set
rt-app: refactor log data to reduce the number of parameters of run()
rt-app: move wu_lat to the end of the log
rt-app: make c_prd c_period and enlarge it
rt-app: add configured run (c_run) to log metrics
doc/tutorial.txt | 25 ++++++++++
libdl/dl_syscalls.h | 4 +-
src/rt-app.c | 113 ++++++++++++++++++++++++++++++++++++----------
src/rt-app_args.h | 3 --
src/rt-app_parse_config.c | 6 ++-
src/rt-app_parse_config.h | 2 +
src/rt-app_types.h | 14 ++++++
src/rt-app_utils.c | 23 ++++++++--
src/rt-app_utils.h | 6 +++
9 files changed, 162 insertions(+), 34 deletions(-)
--
2.10.0
During my time working with the rt-app cpufreq efficiency test I came across a
few rough edges. Patches 1-4 address those.
Patch 5 essentially rewrites the test.sh script. Prior to this patch test.sh
takes a single governor and workload specification (duty cycle). It runs the
workload with this governor as well as the perf and power governors then
calculates efficiency. If we want to profile multiple governors, using this
script would result in running the workload under the perf and power governors
multiple times. You could run dvfs.sh script directly in which case the
efficiency must be manually calculated.
Patch 5 adds support to test.sh to accept a test specification file with the -f
parameter. A test specification file specifies the CPU to run the tests on, the
governors to test (excluding the perf and power governors), and the workloads
to test. It looks like this:
1
ondemand interactive schedutil
1 100 100
10 1000 10
1 10 1000
The workloads are specified as:
<busy time @fmax in ms> <period length in ms> <# of loops>
The results are output in a text-formatted table suitable for email.
CPU frequency residency is also tracked as part of patch 5. At the end of the
testing the residencies for each test for a given governor are printed in a
table. This depends on cpufreq stats being enabled on the platform.
The test.sh script continues to accept arguments as it did previously, i.e. it
will accept a single governor and workload on the command line.
Steve Muckle (5):
rt-app: fix cpufreq test loops
rt-app: change default sched class for dvfs test to SCHED_OTHER
rt-app: tidy up cpufreq efficiency README
rt-app: save and restore governor in dvfs.sh cpufreq efficency test
rt-app: rework cpufreq efficiency script
doc/examples/cpufreq_governor_efficiency/README | 85 ++++---
doc/examples/cpufreq_governor_efficiency/dvfs.json | 4 +-
doc/examples/cpufreq_governor_efficiency/dvfs.sh | 13 +-
doc/examples/cpufreq_governor_efficiency/test.sh | 246 ++++++++++++++-------
4 files changed, 238 insertions(+), 110 deletions(-)
--
2.7.3
