aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorJonathan Herman <hermanjl@cs.unc.edu>2013-04-08 17:01:57 -0400
committerJonathan Herman <hermanjl@cs.unc.edu>2013-04-08 17:01:57 -0400
commit37a410ab7d4ba991a075a3b2f4d24a656f4544ca (patch)
tree5b6a2c921c074820d70db803cfbc83d0e83e18a9
parent40df618c33f56fcdcbc9afc1f4b963e7dfe23a10 (diff)
Updated README.md to reflect recent changes.
-rw-r--r--README.md29
1 files changed, 25 insertions, 4 deletions
diff --git a/README.md b/README.md
index d258900..0798b61 100644
--- a/README.md
+++ b/README.md
@@ -72,12 +72,14 @@ OUT_DIR/[SCHED_(FILE|DIR)/]
72 72
73*Defaults*: `SCHED_FILE = sched.py`, `PARAM_FILE = params.py`, `DURATION = 30`, `OUT_DIR = run-data/` 73*Defaults*: `SCHED_FILE = sched.py`, `PARAM_FILE = params.py`, `DURATION = 30`, `OUT_DIR = run-data/`
74 74
75This script reads *schedule files* (described below) and executes real-time task systems, recording all overhead, logging, and trace data which is enabled in the system. For example, if trace logging is enabled, rt-kernelshark is found in the path, but feather-trace is disabled (the devices are not present), only trace logs and rt-kernelshark logs will be recorded. 75This script reads *schedule files* (described below) and executes real-time task systems, recording all overhead, logging, and trace data which is enabled in the system (unless a specific set of tracers is specified in the parameter file, see below). For example, if trace logging is enabled, rt-kernelshark is found in the path, but feather-trace is disabled (the devices are not present), only trace logs and rt-kernelshark logs will be recorded.
76 76
77When `run_exps.py` is running a schedule file, temporary data is saved in a `tmp` directory in the same directory as the schedule file. When execution completes, this data is moved into a directory under the `run_exps.py` output directory (default: `run-data/`, can be changed with the `-o` option). When multiple schedules are run, each schedule's data is saved in a unique directory under the output directory. 77When `run_exps.py` is running a schedule file, temporary data is saved in a `tmp` directory in the same directory as the schedule file. When execution completes, this data is moved into a directory under the `run_exps.py` output directory (default: `run-data/`, can be changed with the `-o` option). When multiple schedules are run, each schedule's data is saved in a unique directory under the output directory.
78 78
79If a schedule has been run and it's data is in the output directory, `run_exps.py` will not re-run the schedule unless the `-f` option is specified. This is useful if your system crashes midway through a set of experiments. 79If a schedule has been run and it's data is in the output directory, `run_exps.py` will not re-run the schedule unless the `-f` option is specified. This is useful if your system crashes midway through a set of experiments.
80 80
81You can use the `-j` option to send a jabber instant message every time an experiment completes. Running the script with `-j` will print out more details about this option.
82
81Schedule files have one of the following two formats: 83Schedule files have one of the following two formats:
82 84
831. simple format 851. simple format
@@ -115,13 +117,13 @@ $ run_exps.py -s GSN-EDF test.sched
115[Exp test/test.sched]: Enabling sched_trace 117[Exp test/test.sched]: Enabling sched_trace
116... 118...
117[Exp test/test.sched]: Switching to GSN-EDF 119[Exp test/test.sched]: Switching to GSN-EDF
118[Exp test/test.sched]: Starting 3 tracers 120[Exp test/test.sched]: Starting 3 regular tracers
119[Exp test/test.sched]: Starting the programs 121[Exp test/test.sched]: Starting the programs
120[Exp test/test.sched]: Sleeping until tasks are ready for release... 122[Exp test/test.sched]: Sleeping until tasks are ready for release...
121[Exp test/test.sched]: Releasing 3 tasks 123[Exp test/test.sched]: Releasing 3 tasks
122[Exp test/test.sched]: Waiting for program to finish... 124[Exp test/test.sched]: Waiting for program to finish...
123[Exp test/test.sched]: Saving results in /root/schedules/test/run-data/test.sched 125[Exp test/test.sched]: Saving results in /root/schedules/test/run-data/test.sched
124[Exp test/test.sched]: Stopping tracers 126[Exp test/test.sched]: Stopping regular tracers
125[Exp test/test.sched]: Switching to Linux scheduler 127[Exp test/test.sched]: Switching to Linux scheduler
126[Exp test/test.sched]: Experiment done! 128[Exp test/test.sched]: Experiment done!
127Experiments run: 1 129Experiments run: 1
@@ -167,12 +169,27 @@ You can include non-relevant parameters which `run_exps.py` does not understand
167$ mkdir test1 169$ mkdir test1
168# The duration will default to 30 and need not be specified 170# The duration will default to 30 and need not be specified
169$ echo "{'scheduler':'C-EDF', 'test-param':1}" > test1/params.py 171$ echo "{'scheduler':'C-EDF', 'test-param':1}" > test1/params.py
170$ echo "10 20" > test1/sched.py 172$ echo "-p 1 10 20" > test1/sched.py
171$ cp -r test1 test2 173$ cp -r test1 test2
172$ echo "{'scheduler':'GSN-EDF', 'test-param':2}"> test2/params.py 174$ echo "{'scheduler':'GSN-EDF', 'test-param':2}"> test2/params.py
173$ run_exps.py test* 175$ run_exps.py test*
174``` 176```
175 177
178You can specify commands to run before and after each experiment is run using 'pre-experiment' and 'post-experiment'. This is useful for complicated system setup such as managing shared resources. The following example prints out a message before and after an experiment is run (note that command line arguments can be specified using arrays):
179```bash
180$ echo "10 20" > sched.py
181$ echo "{'scheduler':'GSN-EDF',
182'pre-experiment' : 'script1.sh',
183'post-experiment' : ['echo', 'Experiment ends!']}" > params.py
184$ echo "#!/bin/bash
185Experiment begins!" > script1.sh
186$ run_exps.py
187$ cat pre-out.txt
188Experiment begins!
189$ cat post-out.txt
190Experiment ends!
191```
192
176Finally, you can specify system properties in `params.py` which the environment must match for the experiment to run. These are useful if you have a large batch of experiments which must be run under different kernels or kernel configurations. The first property is a regular expression for the name of the kernel: 193Finally, you can specify system properties in `params.py` which the environment must match for the experiment to run. These are useful if you have a large batch of experiments which must be run under different kernels or kernel configurations. The first property is a regular expression for the name of the kernel:
177 194
178```bash 195```bash
@@ -200,6 +217,10 @@ The second property is kernel configuration options. These assume the configurat
200} 217}
201``` 218```
202 219
220The third property is required tracers. The `tracers` property lets the user specify only those tracers they want to run with an experiment, as opposed to starting every available tracer (the default). If any of these specified tracers cannot be enabled, e.g. the kernel was not compiled with feather-trace support, the experiment will not run. The following example gives an experiment which will not run unless all four tracers are enabled:
221```python
222{'tracers':['kernelshark', 'log', 'sched', 'overhead']}
223```
203 224
204## gen_exps.py 225## gen_exps.py
205*Usage*: `gen_exps.py [options] [files...] [generators...] [param=val[,val]...]` 226*Usage*: `gen_exps.py [options] [files...] [generators...] [param=val[,val]...]`