* [rt-tests 0/4] Streamlining code base?
@ 2020-09-02 8:27 Daniel Wagner
2020-09-02 8:27 ` [rt-tests 1/4] cyclicdeadline: Streamline usage output and man page Daniel Wagner
` (4 more replies)
0 siblings, 5 replies; 10+ messages in thread
From: Daniel Wagner @ 2020-09-02 8:27 UTC (permalink / raw)
To: Clark Williams, John Kacur; +Cc: linux-rt-users, Daniel Wagner
Hi Clark and John,
I'd like to streamline all tools, so that the usage, command arguments
and the output is more consistent. Every tool seems to be a bit
different which makes all automatization around the tools more complex
than needed.
Eventually, I'd like to add an easy machine parseable output from all
tools. So what do you think? Stupid effort, go away?
Here are a bunch of patches to illustrate what I mean. Before invest
too much time I'd like to discuss it, e.g. format.
Cheers,
Daniel
Daniel Wagner (4):
cyclicdeadline: Streamline usage output and man page
deadline_test: Streamline usage output and man page
oslat: Streamline usage output and man page
oslat: Use string parser utilies
src/include/rt-utils.h | 1 +
src/lib/rt-utils.c | 30 ++++++
src/oslat/oslat.8 | 2 +-
src/oslat/oslat.c | 143 ++++++++--------------------
src/sched_deadline/cyclicdeadline.8 | 24 ++---
src/sched_deadline/cyclicdeadline.c | 41 ++++----
src/sched_deadline/deadline_test.8 | 37 ++++---
src/sched_deadline/deadline_test.c | 47 +++++----
8 files changed, 145 insertions(+), 180 deletions(-)
--
2.28.0
^ permalink raw reply [flat|nested] 10+ messages in thread* [rt-tests 1/4] cyclicdeadline: Streamline usage output and man page 2020-09-02 8:27 [rt-tests 0/4] Streamlining code base? Daniel Wagner @ 2020-09-02 8:27 ` Daniel Wagner 2020-09-02 8:27 ` [rt-tests 2/4] deadline_test: " Daniel Wagner ` (3 subsequent siblings) 4 siblings, 0 replies; 10+ messages in thread From: Daniel Wagner @ 2020-09-02 8:27 UTC (permalink / raw) To: Clark Williams, John Kacur; +Cc: linux-rt-users, Daniel Wagner Signed-off-by: Daniel Wagner <dwagner@suse.de> --- src/sched_deadline/cyclicdeadline.8 | 24 ++++++++--------- src/sched_deadline/cyclicdeadline.c | 41 +++++++++++++++-------------- 2 files changed, 33 insertions(+), 32 deletions(-) diff --git a/src/sched_deadline/cyclicdeadline.8 b/src/sched_deadline/cyclicdeadline.8 index 91766fb391c4..6df7faf445f9 100644 --- a/src/sched_deadline/cyclicdeadline.8 +++ b/src/sched_deadline/cyclicdeadline.8 @@ -17,7 +17,7 @@ cyclicdeadline \- This program is used to test the deadline scheduler (SCHED_DEA .PP .SH SYNOPSIS .B cyclicdeadline -.RI "[-ha] [-c cpulist] [-i interval] [-s step] [-t nr_threads] [-D duration] +.RI "[-ha] [-c CPUSET] [-D TIME] [-i INTV] [-s STEP] [-t NUM]" .PP .SH DESCRIPTION .B cyclicdeadline @@ -25,28 +25,28 @@ is a cyclictest style program for testing the deadline scheduler .PP .SH OPTIONS .TP -.B \-h -Show this help menu -.TP .B \-a Use all CPUs .TP -.B \-c cpulist +.B \-c CPUSET Comma / hypen separated list of CPUs to run deadline tasks on .TP -.B \-i interval +.B \-D TIME +Specify a length for the test to run +Append 'm', 'h', or 'd' to specify minutes, hours, or days +.TP +.B \-h +Show this help menu +.TP +.B \-i INTV The shortest deadline for the tasks in us. (default 1000us) .TP -.B \-s step +.B \-s STEP The amount to increase the deadline for each task in us. (default 500us) .TP -.B \-t nr_threads +.B \-t NUM The number of threads to run as deadline (default 1) -.TP -.B \-D time -Specify a length for the test to run .br -Append 'm', 'h', or 'd' to specify minutes, hours, or days .SH AUTHOR cyclicdeadline was written by Steven Rostedt <rostedt@goodmis.org> .PP diff --git a/src/sched_deadline/cyclicdeadline.c b/src/sched_deadline/cyclicdeadline.c index a08e28e73c42..310880805553 100644 --- a/src/sched_deadline/cyclicdeadline.c +++ b/src/sched_deadline/cyclicdeadline.c @@ -630,26 +630,25 @@ static void teardown(void) destroy_cpuset(CPUSET_LOCAL, 1); } -static void usage(char **argv) +static void usage(int error) { - char *arg = argv[0]; - char *p = arg+strlen(arg); - - while (p >= arg && *p != '/') - p--; - p++; - - printf("usage: %s [options]\n" - " -h - Show this help menu\n" - " -a - Use all CPUs\n" - " -c cpulist - Comma/hyphen separated list of CPUs to run deadline tasks on\n" - " -i interval(us) - The shortest deadline for the tasks (default 1000us)\n" - " -s step(us) - The amount to increase the deadline for each task (default 500us)\n" - " -t threads - The number of threads to run as deadline (default 1)\n" - " -D time - Specify a length for the test run\n" - " Append 'm', 'h', or 'd' to specify minutes, hours or days\n" - "\n", p); - exit(-1); + printf("cyclicdeadline V %1.2f\n", VERSION); + printf("Usage:\n" + "cyclicdeadline <options>\n\n" + "-a Use all CPUs\n" + "-c CPUSET Comma/hyphen separated list of CPUs to run deadline\n" + " tasks on.\n" + "-D TIME Specify a length for the test run.\n" + " Append 'm', 'h', or 'd' to specify minutes, hours or\n" + " days\n" + "-h Show this help menu.\n" + "-i INTV The shortest deadline for the tasks in us\n" + " (default 1000us).\n" + "-s STEP The amount to increase the deadline for each task in us\n" + " (default 500us).\n" + "-t NUM The number of threads to run as deadline (default 1).\n" + ); + exit(error); } static int fail; @@ -1057,8 +1056,10 @@ int main (int argc, char **argv) duration = parse_time_string(optarg); break; case 'h': + usage(0); + break; default: - usage(argv); + usage(1); } } -- 2.28.0 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* [rt-tests 2/4] deadline_test: Streamline usage output and man page 2020-09-02 8:27 [rt-tests 0/4] Streamlining code base? Daniel Wagner 2020-09-02 8:27 ` [rt-tests 1/4] cyclicdeadline: Streamline usage output and man page Daniel Wagner @ 2020-09-02 8:27 ` Daniel Wagner 2020-09-02 8:27 ` [rt-tests 3/4] oslat: " Daniel Wagner ` (2 subsequent siblings) 4 siblings, 0 replies; 10+ messages in thread From: Daniel Wagner @ 2020-09-02 8:27 UTC (permalink / raw) To: Clark Williams, John Kacur; +Cc: linux-rt-users, Daniel Wagner Signed-off-by: Daniel Wagner <dwagner@suse.de> --- src/sched_deadline/deadline_test.8 | 37 ++++++++++++----------- src/sched_deadline/deadline_test.c | 47 +++++++++++++++--------------- 2 files changed, 41 insertions(+), 43 deletions(-) diff --git a/src/sched_deadline/deadline_test.8 b/src/sched_deadline/deadline_test.8 index 5dc99c0bfc63..8f32c5b6feb6 100644 --- a/src/sched_deadline/deadline_test.8 +++ b/src/sched_deadline/deadline_test.8 @@ -19,45 +19,44 @@ deadline_test \- High resolution test program This program is used to test the deadline scheduler (SCHED_DEADLINE tasks) .SH SYNOPSIS .B deadline_test -.RI "[ \-hb ] [ \-r prio ] [ \-c cpulist ] [ \-i interval ] [ \-p percent ] [ \-P percent ] [ \-t threads ] [ \-s step[us) ]" - +.RI "[ \-hb ] [ \-c CPUSET ] [ \-i INTV ] [ \-p PERCENT ] [ \-P PERCENT ] \ +[ \-r PRIO ] [ \-s STEP ] [ \-t NUM ]" .SH OPTIONS .TP -.B \-h -Show this help menu -.br -.TP .B \-b Bind on the last cpu. (shortcut for -c <lastcpu>) .br .TP -.B \-r prio -Add an RT task with given prio to stress system +.B \-c CPUSET +Comma/hyphen separated list of CPUs to run deadline tasks on .br .TP -.B \-c cpulist -Comma/hyphen separated list of CPUs to run deadline tasks on +.B \-h +Show this help menu .br .TP -.B \-i interval +.B \-i INTV The shortest deadline for the tasks .br .TP -.B \-p percent +.B \-p PERCENT The percent of bandwidth to use (1-90%) .br .TP -.B \-P percent -The percent of runtime for execution completion - (Default 100%) +.B \-P PERCENT +The percent of runtime for execution completion (default 100%) .br .TP -.B \-t threads -The number of threads to run as deadline (default 1) +.B \-r PRIO +Add an RT task with given prio to stress system .br .TP -.B \-s step(us) -The amount to increase the deadline for each task (default 500us) +.B \-s STEP +The amount to increase the deadline for each task in us (default 500us) +.br +.TP +.B \-t NUM +The number of threads to run as deadline (default 1) .br .SH AUTHOR Deadline test was written by Steven Rostedt <rostedt@goodmis.org> diff --git a/src/sched_deadline/deadline_test.c b/src/sched_deadline/deadline_test.c index 4cef2609912e..060ac896aef2 100644 --- a/src/sched_deadline/deadline_test.c +++ b/src/sched_deadline/deadline_test.c @@ -46,33 +46,30 @@ /** * usage - show the usage of the program and exit. - * @argv: The program passed in args + * @error: Exit error code to be used * - * This is defined here to show people looking at this code how + * This is defined here to show peoplde looking at this code how * to use this program as well. */ -static void usage(char **argv) +static void usage(int error) { - char *arg = argv[0]; - char *p = arg+strlen(arg); - - while (p >= arg && *p != '/') - p--; - p++; - - printf("usage: %s [options]\n" - " -h - Show this help menu\n" - " -b - Bind on the last cpu. (shortcut for -c <lastcpu>)\n" - " -r prio - Add an RT task with given prio to stress system\n" - " -c cpulist - Comma/hyphen separated list of CPUs to run deadline tasks on\n" - " -i interval - The shortest deadline for the tasks\n" - " -p percent - The percent of bandwidth to use (1-90%%)\n" - " -P percent - The percent of runtime for execution completion\n" - " (Default 100%%)\n" - " -t threads - The number of threads to run as deadline (default 1)\n" - " -s step(us) - The amount to increase the deadline for each task (default 500us)\n" - "\n", p); - exit(-1); + printf("deadline_test V %1.2f\n", VERSION); + printf("Usage:\n" + "deadline_test <options>\n" + "-b Bind on the last cpu. (shortcut for -c <lastcpu>)\n" + "-c CPUSET Comma/hyphen separated list of CPUs to run deadline\n" + " tasks on\n" + "-h Show this help menu\n" + "-i INTV The shortest deadline for the tasks\n" + "-p PERCENT The percent of bandwidth to use (1-90%%)\n" + "-P PERCENT The percent of runtime for execution completion\n" + " (default 100%%)\n" + "-r PRIO Add an RT task with given prio to stress system\n" + "-s STEP The amount to increase the deadline for each task in us\n" + " (default 500us)\n" + "-t NUM The number of threads to run as deadline (default 1)\n" + ); + exit(error); } #define _STR(x) #x @@ -1753,8 +1750,10 @@ int main (int argc, char **argv) rt_task = atoi(optarg); break; case 'h': + usage(0); + break; default: - usage(argv); + usage(1); } } -- 2.28.0 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* [rt-tests 3/4] oslat: Streamline usage output and man page 2020-09-02 8:27 [rt-tests 0/4] Streamlining code base? Daniel Wagner 2020-09-02 8:27 ` [rt-tests 1/4] cyclicdeadline: Streamline usage output and man page Daniel Wagner 2020-09-02 8:27 ` [rt-tests 2/4] deadline_test: " Daniel Wagner @ 2020-09-02 8:27 ` Daniel Wagner 2020-09-02 8:27 ` [rt-tests 4/4] oslat: Use string parser utilies Daniel Wagner 2020-09-04 1:39 ` [rt-tests 0/4] Streamlining code base? Clark Williams 4 siblings, 0 replies; 10+ messages in thread From: Daniel Wagner @ 2020-09-02 8:27 UTC (permalink / raw) To: Clark Williams, John Kacur; +Cc: linux-rt-users, Daniel Wagner Signed-off-by: Daniel Wagner <dwagner@suse.de> --- src/oslat/oslat.8 | 2 +- src/oslat/oslat.c | 76 +++++++++++++++++++++++------------------------ 2 files changed, 38 insertions(+), 40 deletions(-) diff --git a/src/oslat/oslat.8 b/src/oslat/oslat.8 index 85f2c5bcdf5c..b481d8d82783 100644 --- a/src/oslat/oslat.8 +++ b/src/oslat/oslat.8 @@ -36,7 +36,7 @@ Total memory usage will be this value multiplies 2*N, because there will be src/dst buffers for each thread, and N is the number of processors for testing. .TP -.B \-t, \-\-runtime=SEC +.B \-D, \-\-duration=TIME Specify test duration, e.g., 60, 20m, 2H (m/M: minutes, h/H: hours, d/D: days). By default the unit is s/second. .TP diff --git a/src/oslat/oslat.c b/src/oslat/oslat.c index f1a82f2367d2..79d2b6754461 100644 --- a/src/oslat/oslat.c +++ b/src/oslat/oslat.c @@ -507,42 +507,37 @@ static void handle_alarm(int code) g.cmd = STOP; } -const char *helpmsg = -"Usage: %s [options]\n" -"\n" -"This is an OS latency detector by running busy loops on specified cores.\n" -"Please run this tool using root.\n" -"\n" -"Available options:\n" -"\n" -" -b, --bucket-size Specify the number of the buckets (4-1024)\n" -" -B, --bias Add a bias to all the buckets using the estimated mininum\n" -" -c, --cpu-list Specify CPUs to run on, e.g. '1,3,5,7-15'\n" -" -C, --cpu-main-thread Specify which CPU the main thread runs on. Default is cpu0.\n" -" -f, --rtprio Using SCHED_FIFO priority (1-99)\n" -" -m, --workload-mem Size of the memory to use for the workload (e.g., 4K, 1M).\n" -" Total memory usage will be this value multiplies 2*N,\n" -" because there will be src/dst buffers for each thread, and\n" -" N is the number of processors for testing.\n" -" -s, --single-preheat Use a single thread when measuring latency at preheat stage\n" -" NOTE: please make sure the CPU frequency on all testing cores\n" -" are locked before using this parmater. If you don't know how\n" -" to lock the freq then please don't use this parameter.\n" -" -t, --runtime Specify test duration, e.g., 60, 20m, 2H\n" -" (m/M: minutes, h/H: hours, d/D: days)\n" -" -T, --trace-threshold Stop the test when threshold triggered (in us),\n" -" print a marker in ftrace and stop ftrace too.\n" -" -v, --version Display the version of the software.\n" -" -w, --workload Specify a kind of workload, default is no workload\n" -" (options: no, memmove)\n" -" -z, --zero-omit Don't display buckets in the output histogram if all zeros.\n" -"\n" -; - -static void usage(void) +static void usage(int error) { - printf(helpmsg, g.app_name); - exit(1); + printf("oslat V %1.2f\n", VERSION); + printf("Usage:\n" + "oslat <options>\n\n" + "This is an OS latency detector by running busy loops on specified cores.\n" + "Please run this tool using root.\n\n" + "Available options:\n\n" + "-b, --bucket-size Specify the number of the buckets (4-1024)\n" + "-B, --bias Add a bias to all the buckets using the estimated mininum\n" + "-c, --cpu-list Specify CPUs to run on, e.g. '1,3,5,7-15'\n" + "-C, --cpu-main-thread Specify which CPU the main thread runs on. Default is cpu0.\n" + "-D, --duration Specify test duration, e.g., 60, 20m, 2H\n" + " (m/M: minutes, h/H: hours, d/D: days)\n" + "-f, --rtprio Using SCHED_FIFO priority (1-99)\n" + "-m, --workload-mem Size of the memory to use for the workload (e.g., 4K, 1M).\n" + " Total memory usage will be this value multiplies 2*N,\n" + " because there will be src/dst buffers for each thread, and\n" + " N is the number of processors for testing.\n" + "-s, --single-preheat Use a single thread when measuring latency at preheat stage\n" + " NOTE: please make sure the CPU frequency on all testing cores\n" + " are locked before using this parmater. If you don't know how\n" + " to lock the freq then please don't use this parameter.\n" + "-T, --trace-threshold Stop the test when threshold triggered (in us),\n" + " print a marker in ftrace and stop ftrace too.\n" + "-v, --version Display the version of the software.\n" + "-w, --workload Specify a kind of workload, default is no workload\n" + " (options: no, memmove)\n" + "-z, --zero-omit Don't display buckets in the output histogram if all zeros.\n" + ); + exit(error); } /* TODO: use libnuma? */ @@ -661,7 +656,7 @@ static void parse_options(int argc, char *argv[]) { "bucket-size", required_argument, NULL, 'b' }, { "cpu-list", required_argument, NULL, 'c' }, { "cpu-main-thread", required_argument, NULL, 'C'}, - { "runtime", required_argument, NULL, 't' }, + { "duration", required_argument, NULL, 'D' }, { "rtprio", required_argument, NULL, 'f' }, { "help", no_argument, NULL, 'h' }, { "trace-threshold", required_argument, NULL, 'T' }, @@ -673,7 +668,7 @@ static void parse_options(int argc, char *argv[]) { "version", no_argument, NULL, 'v'}, { NULL, 0, NULL, 0 }, }; - int i, c = getopt_long(argc, argv, "b:Bc:C:f:hm:st:w:T:vz", + int i, c = getopt_long(argc, argv, "b:Bc:C:D:f:hm:sw:T:vz", options, NULL); long ncores; @@ -704,7 +699,7 @@ static void parse_options(int argc, char *argv[]) exit(1); } break; - case 't': + case 'D': g.runtime = parse_runtime(optarg); if (!g.runtime) { printf("Illegal runtime: %s\n", optarg); @@ -761,8 +756,11 @@ static void parse_options(int argc, char *argv[]) case 'z': g.output_omit_zero_buckets = 1; break; + case 'h': + usage(0); + break; default: - usage(); + usage(1); break; } } -- 2.28.0 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* [rt-tests 4/4] oslat: Use string parser utilies 2020-09-02 8:27 [rt-tests 0/4] Streamlining code base? Daniel Wagner ` (2 preceding siblings ...) 2020-09-02 8:27 ` [rt-tests 3/4] oslat: " Daniel Wagner @ 2020-09-02 8:27 ` Daniel Wagner 2020-09-04 1:39 ` [rt-tests 0/4] Streamlining code base? Clark Williams 4 siblings, 0 replies; 10+ messages in thread From: Daniel Wagner @ 2020-09-02 8:27 UTC (permalink / raw) To: Clark Williams, John Kacur; +Cc: linux-rt-users, Daniel Wagner Use available parse_time_string() instead locally implemented version. While at it move the mem parser helper to the global utility header. Signed-off-by: Daniel Wagner <dwagner@suse.de> --- src/include/rt-utils.h | 1 + src/lib/rt-utils.c | 30 +++++++++++++++++++ src/oslat/oslat.c | 67 ++---------------------------------------- 3 files changed, 33 insertions(+), 65 deletions(-) diff --git a/src/include/rt-utils.h b/src/include/rt-utils.h index 4ed1cbc53ece..d7f369cdbb47 100644 --- a/src/include/rt-utils.h +++ b/src/include/rt-utils.h @@ -28,6 +28,7 @@ uint32_t string_to_policy(const char *str); pid_t gettid(void); int parse_time_string(char *val); +int parse_mem_string(char *str, uint64_t *val); void enable_trace_mark(void); void tracemark(char *fmt, ...) __attribute__((format(printf, 1, 2))); diff --git a/src/lib/rt-utils.c b/src/lib/rt-utils.c index f786588706cd..f9cbfb82febb 100644 --- a/src/lib/rt-utils.c +++ b/src/lib/rt-utils.c @@ -362,6 +362,36 @@ int parse_time_string(char *val) return t; } +int parse_mem_string(char *str, uint64_t *val) +{ + char *endptr; + int v = strtol(str, &endptr, 10); + + if (!*endptr) + return v; + + switch (*endptr) { + case 'g': + case 'G': + v *= 1024; + case 'm': + case 'M': + v *= 1024; + case 'k': + case 'K': + v *= 1024; + case 'b': + case 'B': + break; + default: + return -1; + } + + *val = v; + + return 0; +} + void open_tracemark_fd(void) { char path[MAX_PATH]; diff --git a/src/oslat/oslat.c b/src/oslat/oslat.c index 79d2b6754461..3a5acae95c1f 100644 --- a/src/oslat/oslat.c +++ b/src/oslat/oslat.c @@ -570,69 +570,6 @@ static int parse_cpu_list(char *cpu_list, cpu_set_t *cpu_set) return n_cores; } -static int parse_runtime(const char *str) -{ - char *endptr; - int v = strtol(str, &endptr, 10); - - if (!*endptr) - return v; - - switch (*endptr) { - case 'd': - case 'D': - /* Days */ - v *= 24; - case 'h': - case 'H': - /* Hours */ - v *= 60; - case 'm': - case 'M': - /* Minutes */ - v *= 60; - case 's': - case 'S': - /* Seconds */ - break; - default: - printf("Unknown runtime suffix: %s\n", endptr); - v = 0; - break; - } - - return v; -} - -static int parse_mem_size(char *str, uint64_t *val) -{ - char *endptr; - int v = strtol(str, &endptr, 10); - - if (!*endptr) - return v; - - switch (*endptr) { - case 'g': - case 'G': - v *= 1024; - case 'm': - case 'M': - v *= 1024; - case 'k': - case 'K': - v *= 1024; - case 'b': - case 'B': - break; - default: - return -1; - } - - *val = v; - - return 0; -} static int workload_select(char *name) { @@ -700,7 +637,7 @@ static void parse_options(int argc, char *argv[]) } break; case 'D': - g.runtime = parse_runtime(optarg); + g.runtime = parse_time_string(optarg); if (!g.runtime) { printf("Illegal runtime: %s\n", optarg); exit(1); @@ -734,7 +671,7 @@ static void parse_options(int argc, char *argv[]) } break; case 'm': - if (parse_mem_size(optarg, &g.workload_mem_size)) { + if (parse_mem_string(optarg, &g.workload_mem_size)) { printf("Unknown workload memory size '%s'.\n\n", optarg); exit(1); } -- 2.28.0 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [rt-tests 0/4] Streamlining code base? 2020-09-02 8:27 [rt-tests 0/4] Streamlining code base? Daniel Wagner ` (3 preceding siblings ...) 2020-09-02 8:27 ` [rt-tests 4/4] oslat: Use string parser utilies Daniel Wagner @ 2020-09-04 1:39 ` Clark Williams 2020-09-04 6:31 ` Daniel Wagner 4 siblings, 1 reply; 10+ messages in thread From: Clark Williams @ 2020-09-04 1:39 UTC (permalink / raw) To: Daniel Wagner; +Cc: John Kacur, linux-rt-users On Wed, 2 Sep 2020 10:27:21 +0200 Daniel Wagner <dwagner@suse.de> wrote: > Hi Clark and John, > > I'd like to streamline all tools, so that the usage, command arguments > and the output is more consistent. Every tool seems to be a bit > different which makes all automatization around the tools more complex > than needed. > > Eventually, I'd like to add an easy machine parseable output from all > tools. So what do you think? Stupid effort, go away? I think it's a noble goal and I'd be up for it, especially trying to come up with a parsable output format. Got any thoughts on it? Personally I'd go for (in order of preference): XML JSON Random Gibberish Any Damned thing YAML Clark Did I mention that I hate YAML? > > Here are a bunch of patches to illustrate what I mean. Before invest > too much time I'd like to discuss it, e.g. format. > > Cheers, > Daniel > > Daniel Wagner (4): > cyclicdeadline: Streamline usage output and man page > deadline_test: Streamline usage output and man page > oslat: Streamline usage output and man page > oslat: Use string parser utilies > > src/include/rt-utils.h | 1 + > src/lib/rt-utils.c | 30 ++++++ > src/oslat/oslat.8 | 2 +- > src/oslat/oslat.c | 143 ++++++++-------------------- > src/sched_deadline/cyclicdeadline.8 | 24 ++--- > src/sched_deadline/cyclicdeadline.c | 41 ++++---- > src/sched_deadline/deadline_test.8 | 37 ++++--- > src/sched_deadline/deadline_test.c | 47 +++++---- > 8 files changed, 145 insertions(+), 180 deletions(-) > > -- > 2.28.0 > -- The United States Coast Guard Ruining Natural Selection since 1790 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [rt-tests 0/4] Streamlining code base? 2020-09-04 1:39 ` [rt-tests 0/4] Streamlining code base? Clark Williams @ 2020-09-04 6:31 ` Daniel Wagner 2020-09-04 15:40 ` John Kacur 0 siblings, 1 reply; 10+ messages in thread From: Daniel Wagner @ 2020-09-04 6:31 UTC (permalink / raw) To: Clark Williams; +Cc: Daniel Wagner, John Kacur, linux-rt-users On Thu, Sep 03, 2020 at 08:39:48PM -0500, Clark Williams wrote: > I think it's a noble goal and I'd be up for it, especially trying to come > up with a parsable output format. Got any thoughts on it? Personally I'd > go for (in order of preference): > > XML > JSON > Random Gibberish > Any Damned thing > YAML For jitterdebugger I ended up adding a bunch of plugins for the output format. So I don't have to argue which format it best, though if I had to choose I'd properly pick JSON. > Did I mention that I hate YAML? Named must be your fear before banish it you can. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [rt-tests 0/4] Streamlining code base? 2020-09-04 6:31 ` Daniel Wagner @ 2020-09-04 15:40 ` John Kacur 2020-09-07 8:13 ` Daniel Wagner 0 siblings, 1 reply; 10+ messages in thread From: John Kacur @ 2020-09-04 15:40 UTC (permalink / raw) To: Daniel Wagner; +Cc: Clark Williams, Daniel Wagner, linux-rt-users On Fri, 4 Sep 2020, Daniel Wagner wrote: > On Thu, Sep 03, 2020 at 08:39:48PM -0500, Clark Williams wrote: > > I think it's a noble goal and I'd be up for it, especially trying to come > > up with a parsable output format. Got any thoughts on it? Personally I'd > > go for (in order of preference): > > > > XML > > JSON > > Random Gibberish > > Any Damned thing > > YAML > > For jitterdebugger I ended up adding a bunch of plugins for the output > format. So I don't have to argue which format it best, though if I had > to choose I'd properly pick JSON. > > > Did I mention that I hate YAML? > > Named must be your fear before banish it you can. > We have some software called rteval that parses the output of cyclictest. https://git.kernel.org/pub/scm/utils/rteval/rteval.git/ (I'll take patches for that too) It runs cyclictest under-the-covers like this cyclictest -qmu -h 2000 -p95 -t -a and parses the output. The output is then transformed into XML. What I like about this, is that it keeps cyclictest lightweight since the data it parses is just text. Then rteval could generate whatever kind of output you are interested in. xml for clark, yaml for the yammering crowd and so on. I'm not saying this is the only legitimate approach, but I would like to keep the individual tools lightweight in rt-tests, so that you could run them individually in the embedded space as well as on large machines. So one way to start would be to make sure that the other tools in the rt-tests suite are capable of generating a similar kind of output, that could then be processed by other tools. John ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [rt-tests 0/4] Streamlining code base? 2020-09-04 15:40 ` John Kacur @ 2020-09-07 8:13 ` Daniel Wagner 2020-09-08 15:23 ` John Kacur 0 siblings, 1 reply; 10+ messages in thread From: Daniel Wagner @ 2020-09-07 8:13 UTC (permalink / raw) To: John Kacur; +Cc: Clark Williams, Daniel Wagner, linux-rt-users On Fri, Sep 04, 2020 at 11:40:06AM -0400, John Kacur wrote: > I'm not saying this is the only legitimate approach, but I would like to > keep the individual tools lightweight in rt-tests, so that you could run > them individually in the embedded space as well as on large machines. Sure, though I still think it would make sense to keep it flexible and have a compile switch if needed. I'd like to avoid additional steps between the measurement and interpretation. Any time we want to add/change a thing, we need to touch more places. Furthermore, if you look at my implementation for the JSON output of jitterdebugger is really small: https://github.com/igaw/jitterdebugger/blob/master/jitterdebugger.c#L158 Adding a XML version for this should be in the same size. If you insist on a single format (XML) that's also okay for me. Python ships all the necessary libraries these days. Though the JSON format is simpler to transform into native data types such as dictionaries and lists, IMO. Anyway, I don't have any strong feeling and have no real problem with one format and a transform script. > So one way to start would be to make sure that the other tools in the > rt-tests suite are capable of generating a similar kind of output, that > could then be processed by other tools. Yes, I'd like to get consistent output from all tools. Though I think we should start from the beginning and getting all command line arguments parser, help texts and man pages consistent. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [rt-tests 0/4] Streamlining code base? 2020-09-07 8:13 ` Daniel Wagner @ 2020-09-08 15:23 ` John Kacur 0 siblings, 0 replies; 10+ messages in thread From: John Kacur @ 2020-09-08 15:23 UTC (permalink / raw) To: Daniel Wagner; +Cc: Clark Williams, Daniel Wagner, linux-rt-users On Mon, 7 Sep 2020, Daniel Wagner wrote: > On Fri, Sep 04, 2020 at 11:40:06AM -0400, John Kacur wrote: > > I'm not saying this is the only legitimate approach, but I would like to > > keep the individual tools lightweight in rt-tests, so that you could run > > them individually in the embedded space as well as on large machines. > > Sure, though I still think it would make sense to keep it flexible and > have a compile switch if needed. I'd like to avoid additional steps > between the measurement and interpretation. Any time we want to > add/change a thing, we need to touch more places. > > Furthermore, if you look at my implementation for the JSON output of > jitterdebugger is really small: > > https://github.com/igaw/jitterdebugger/blob/master/jitterdebugger.c#L158 > > Adding a XML version for this should be in the same size. > > If you insist on a single format (XML) that's also okay for me. Python > ships all the necessary libraries these days. Though the JSON format is > simpler to transform into native data types such as dictionaries and > lists, IMO. If you just read a text stream like rteval does, and store in a native data type, then it is trivial to output any data format. However, your implementation for your jitterdebugger is truly small, I don't want to stomp on your creativity, so spin off a git branch and go to it. I can be persuaded. John ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2020-09-08 19:55 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-09-02 8:27 [rt-tests 0/4] Streamlining code base? Daniel Wagner 2020-09-02 8:27 ` [rt-tests 1/4] cyclicdeadline: Streamline usage output and man page Daniel Wagner 2020-09-02 8:27 ` [rt-tests 2/4] deadline_test: " Daniel Wagner 2020-09-02 8:27 ` [rt-tests 3/4] oslat: " Daniel Wagner 2020-09-02 8:27 ` [rt-tests 4/4] oslat: Use string parser utilies Daniel Wagner 2020-09-04 1:39 ` [rt-tests 0/4] Streamlining code base? Clark Williams 2020-09-04 6:31 ` Daniel Wagner 2020-09-04 15:40 ` John Kacur 2020-09-07 8:13 ` Daniel Wagner 2020-09-08 15:23 ` John Kacur
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).