linux-rt-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [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).