[RFC 0/4] cyclictest: improve running under trace-cmd

[RFC 0/4] cyclictest: improve running under trace-cmd

[Luiz Capitulino]

In short, this series allows you to run cyclictest under
trace-cmd and still get trace marks when the latency
specified with -b is execeded. More details in patch 4/4.

This series is RFC because I'm not completely sure this
is the right thing to do. I'm wondering if we shouldn't
ditch all tracing support from cyclictest...

Luiz Capitulino (4):
  cyclictest: tracing(): check for notrace
  cyclictest: move debugfs init code to its own function
  cyclictest: move tracemark_fd handling to its own function
  cyclictest: add --tracemark option

 src/cyclictest/cyclictest.c | 62 ++++++++++++++++++++++++++++++++++-----------
 1 file changed, 47 insertions(+), 15 deletions(-)

-- 
2.1.0

[RFC 1/4] cyclictest: tracing(): check for notrace

[Luiz Capitulino]

If you pass -b and --notrace to cyclictest today, it will
write to tracing_on when -b latency is reached.

Fix this by making tracing() check notrace.

Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
---
 src/cyclictest/cyclictest.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/cyclictest/cyclictest.c b/src/cyclictest/cyclictest.c
index 34053c5..54fc033 100644
--- a/src/cyclictest/cyclictest.c
+++ b/src/cyclictest/cyclictest.c
@@ -444,6 +444,9 @@ static void tracemark(char *fmt, ...)
 
 void tracing(int on)
 {
+	if (notrace)
+		return;
+
 	if (on) {
 		switch (kernelversion) {
 		case KV_26_LT18: gettimeofday(0,(struct timezone *)1); break;
@@ -1634,7 +1637,7 @@ static void sighand(int sig)
 	shutdown = 1;
 	if (refresh_on_max)
 		pthread_cond_signal(&refresh_on_max_cond);
-	if (tracelimit && !notrace)
+	if (tracelimit)
 		tracing(0);
 }
 
@@ -2164,7 +2167,7 @@ int main(int argc, char **argv)
 	}
  out:
 	/* ensure that the tracer is stopped */
-	if (tracelimit && !notrace)
+	if (tracelimit)
 		tracing(0);
 
 
-- 
2.1.0

[RFC 2/4] cyclictest: move debugfs init code to its own function

[Luiz Capitulino]

A function added by a future commit will want to call
this code too.

Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
---
 src/cyclictest/cyclictest.c | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/src/cyclictest/cyclictest.c b/src/cyclictest/cyclictest.c
index 54fc033..f543c34 100644
--- a/src/cyclictest/cyclictest.c
+++ b/src/cyclictest/cyclictest.c
@@ -479,11 +479,8 @@ static int settracer(char *tracer)
 	return -1;
 }
 
-static void setup_tracer(void)
+static void debugfs_prepare(void)
 {
-	if (!tracelimit || notrace)
-		return;

[RFC 3/4] cyclictest: move tracemark_fd handling to its own function

[Luiz Capitulino]

A function added by the next commit will want to call
this code too.

Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
---
 src/cyclictest/cyclictest.c | 22 ++++++++++++++--------
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/src/cyclictest/cyclictest.c b/src/cyclictest/cyclictest.c
index f543c34..e35088b 100644
--- a/src/cyclictest/cyclictest.c
+++ b/src/cyclictest/cyclictest.c
@@ -497,6 +497,19 @@ static void debugfs_prepare(void)
 		fileprefix = procfileprefix;
 }
 
+static void open_tracemark_fd(void)
+{
+	char path[MAX_PATH];
+
+	if (tracemark_fd >= 0)
+		return;
+
+	sprintf(path, "%s/%s", fileprefix, "trace_marker");
+	tracemark_fd = open(path, O_WRONLY);
+	if (tracemark_fd < 0)
+		warn("unable to open trace_marker file: %s\n", path);
+}
+
 static void setup_tracer(void)
 {
 	if (!tracelimit || notrace)
@@ -612,14 +625,7 @@ static void setup_tracer(void)
 				fatal("unable to open %s for tracing", path);
 		}
 
-		/* open the tracemark file descriptor */
-		if (tracemark_fd == -1) {
-			char path[MAX_PATH];
-			strcat(strcpy(path, fileprefix), "trace_marker");
-			if ((tracemark_fd = open(path, O_WRONLY)) == -1)
-				warn("unable to open trace_marker file: %s\n", path);
-		}

[RFC 4/4] cyclictest: add --tracemark option

[Luiz Capitulino]

cyclictest will only write to /sys/kernel/debug/tracing/trace_maker
if it's also setup to do tracing. This conflicts with
running cyclictest under trace-cmd.

The --tracemark option tells cyclictest to write to the
trace_marker file even when it's not doing tracing.

It's can be used like this:

 # trace-cmd record [...] cyclictest [...] -bX --tracemark --notrace

Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
---
 src/cyclictest/cyclictest.c | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/src/cyclictest/cyclictest.c b/src/cyclictest/cyclictest.c
index e35088b..5a261e2 100644
--- a/src/cyclictest/cyclictest.c
+++ b/src/cyclictest/cyclictest.c
@@ -167,6 +167,7 @@ struct thread_stat {
 static int shutdown;
 static int tracelimit = 0;
 static int notrace = 0;
+static int trace_marker = 0;
 static int ftrace = 0;
 static int kernelversion;
 static int verbose = 0;
@@ -510,6 +511,18 @@ static void open_tracemark_fd(void)
 		warn("unable to open trace_marker file: %s\n", path);
 }
 
+static void enable_trace_mark(void)
+{
+	if (!trace_marker)
+		return;
+
+	if (!tracelimit)
+		fatal("--tracemark requires -b\n");
+
+	debugfs_prepare();
+	open_tracemark_fd();
+}
+
 static void setup_tracer(void)
 {
 	if (!tracelimit || notrace)
@@ -1234,7 +1247,7 @@ enum option_values {
 	OPT_QUIET, OPT_PRIOSPREAD, OPT_RELATIVE, OPT_RESOLUTION, OPT_SYSTEM,
 	OPT_SMP, OPT_THREADS, OPT_TRACER, OPT_UNBUFFERED, OPT_NUMA, OPT_VERBOSE,
 	OPT_WAKEUP, OPT_WAKEUPRT, OPT_DBGCYCLIC, OPT_POLICY, OPT_HELP, OPT_NUMOPTS,
-	OPT_ALIGNED, OPT_LAPTOP, OPT_SECALIGNED,
+	OPT_ALIGNED, OPT_LAPTOP, OPT_SECALIGNED, OPT_TRACEMARK,
 };
 
 /* Process commandline options */
@@ -1285,6 +1298,7 @@ static void process_options (int argc, char *argv[], int max_cpus)
 			{"system",           no_argument,       NULL, OPT_SYSTEM },
 			{"smp",              no_argument,       NULL, OPT_SMP },
 			{"threads",          optional_argument, NULL, OPT_THREADS },
+			{"tracemark",        no_argument,       NULL, OPT_TRACEMARK },
 			{"tracer",           required_argument, NULL, OPT_TRACER },
 			{"unbuffered",       no_argument,       NULL, OPT_UNBUFFERED },
 			{"numa",             no_argument,       NULL, OPT_NUMA },
@@ -1509,6 +1523,8 @@ static void process_options (int argc, char *argv[], int max_cpus)
 			ct_debug = 1; break;
 		case OPT_LAPTOP:
 			laptop = 1; break;
+		case OPT_TRACEMARK:
+			trace_marker = 1; break;
 		}
 	}
 
@@ -1850,6 +1866,8 @@ int main(int argc, char **argv)
 
 	setup_tracer();
 
+	enable_trace_mark();
+
 	if (check_timer())
 		warn("High resolution timers not available\n");
 
-- 
2.1.0

Re: [RFC 0/4] cyclictest: improve running under trace-cmd

[John Kacur]

On Tue, 23 Feb 2016, Luiz Capitulino wrote:

> 
> In short, this series allows you to run cyclictest under
> trace-cmd and still get trace marks when the latency
> specified with -b is execeded. More details in patch 4/4.
> 
> This series is RFC because I'm not completely sure this
> is the right thing to do. I'm wondering if we shouldn't
> ditch all tracing support from cyclictest...
> 
> Luiz Capitulino (4):
>   cyclictest: tracing(): check for notrace
>   cyclictest: move debugfs init code to its own function
>   cyclictest: move tracemark_fd handling to its own function
>   cyclictest: add --tracemark option
> 
>  src/cyclictest/cyclictest.c | 62 ++++++++++++++++++++++++++++++++++-----------
>  1 file changed, 47 insertions(+), 15 deletions(-)
> 
> -- 

Hi. First of all, although I didn't look closely at the details yet, I 
like this set of patches. Just to let you and everyone else know where we 
are, Clark and I are going to put rt-tests into maintainence mode very 
shortly. We want to create a 1.0 version of it, which we will maintain 
with fixes, but no new features. This last set of patches would be a nice 
addition before we go into mainatinence mode so that the old code base 
would have a way of using trace-cmd.

For the next development line of rt-tests, we would like to rip-out all of 
the tracing code that we can, and leave the bare minimum in place to 
interact with trace-cmd. With that in mind, could you go over your RFC 
patches, and if you are satisfied that they don't break anything, but 
allow tracing under trace-cmd, then this could be the last new feature we 
let in. Let me know and I'll review at that point. I'll make and official 
announcement about maintainence mode and a new development line in a 
separate mail as well.

Thank You!

John Kacur

Re: [RFC 0/4] cyclictest: improve running under trace-cmd

[Luiz Capitulino]

On Wed, 24 Feb 2016 18:08:58 +0100 (CET)
John Kacur <jkacur@redhat.com> wrote:

> On Tue, 23 Feb 2016, Luiz Capitulino wrote:
> 
> > 
> > In short, this series allows you to run cyclictest under
> > trace-cmd and still get trace marks when the latency
> > specified with -b is execeded. More details in patch 4/4.
> > 
> > This series is RFC because I'm not completely sure this
> > is the right thing to do. I'm wondering if we shouldn't
> > ditch all tracing support from cyclictest...
> > 
> > Luiz Capitulino (4):
> >   cyclictest: tracing(): check for notrace
> >   cyclictest: move debugfs init code to its own function
> >   cyclictest: move tracemark_fd handling to its own function
> >   cyclictest: add --tracemark option
> > 
> >  src/cyclictest/cyclictest.c | 62 ++++++++++++++++++++++++++++++++++-----------
> >  1 file changed, 47 insertions(+), 15 deletions(-)
> > 
> > -- 
> 
> Hi. First of all, although I didn't look closely at the details yet, I 
> like this set of patches. Just to let you and everyone else know where we 
> are, Clark and I are going to put rt-tests into maintainence mode very 
> shortly. We want to create a 1.0 version of it, which we will maintain 
> with fixes, but no new features. This last set of patches would be a nice 
> addition before we go into mainatinence mode so that the old code base 
> would have a way of using trace-cmd.

OK, that's good to know because I have more patches pending but I
don't want to disturb your plans and workflow.

Regarding this series, what I want to achieve is:

 1. Use trace-cmd for tracing
 2. Get cyclictest to write to the trace_marker file when it
    exceeds the -b latency treshold

By reading the code this seems to be impossible to achieve today,
as you need to pass --notrace to use trace-cmd for tracing and
--notrace will disable writing to the trace_maker.

If what I just described is correct, then we need this series.

> For the next development line of rt-tests, we would like to rip-out all of 
> the tracing code that we can, and leave the bare minimum in place to 
> interact with trace-cmd. With that in mind, could you go over your RFC 
> patches, and if you are satisfied that they don't break anything, but 
> allow tracing under trace-cmd, then this could be the last new feature we 
> let in. Let me know and I'll review at that point. I'll make and official 
> announcement about maintainence mode and a new development line in a 
> separate mail as well.

OK, I'll do a second pass on this series, test it more, and send
a non-RFC version for inclusion.

I also have a small series with very minor fixups. I don't know
if they are important, but I'll post it shortly.