Re: [PATCH] cyclictest: stop any tracing after hitting a breaktrace threshold

From: Clark Williams
Date: Tue May 03 2016 - 16:28:50 EST

On Tue, 3 May 2016 15:56:44 -0400
Luiz Capitulino <lcapitulino@xxxxxxxxxx> wrote:

> On Tue, 3 May 2016 12:59:53 -0500
> Clark Williams <williams@xxxxxxxxxx> wrote:
> > John,
> >
> > This patch is against the devel/v0.98 branch. It turns off tracing in the tracemark() so that we don't lose information about what was going on when we hit the latency:
> >
> >
> > The current logic of using --tracemark and --notrace works for running
> > cyclictest with trace-cmd, but even if we are not doing any trace
> > manipulation in cyclictest, we still need to stop tracing when we hit a
> > breaktrace threshold (i.e. -b <n>).
> Does it solve the problem for you if you revert ba4dd1bf54 and start
> cyclictest with:
> # cyclictest [...] -bX
> Or with:
> # cyclictest [...] -bX --tracemark
> Also, how do I reproduce your issue? Are you doing tracing by hand?

I'm running:
trace-cmd start -e all -p function

Then kicking off loads and finally running:
cyclictest --numa -p95 -qmu -b 300 --tracemark --notrace

The intent here is that cyclictest do nothing wrt tracing other than stop it when the breaktrace threshold is set.

> > +
> > + /* write the tracemark message */
> > write(tracemark_fd, tracebuf, len);
> > +
> > + /* now stop any trace */
> > + write(trace_fd, "0\n", 2);
> > }
> We do tracing(0) when we hit the latency threshold, so I don't
> think this is necessary.

Tracing didn't seem to stop in my scenario above. I suspect it's the --notrace option, which I used to make absolutely certain we didn't touch any tracing bits.

> However, have you checked that writing to tracing_on won't break
> trace-cmd when it exec()ed cyclictest?

I haven't run cyclictest as a child of trace-cmd. I'll try that, but my use-case is really in running rteval, which runs cyclictest as a measurement tool. So for tracing I need to to 'trace-cmd start' before running rteval.

The intent is to be able to do something like this:

trace-cmd start -e all -p function
rteval --duration=12h --cyclictest-breaktrace=150
trace-cmd extract

That sets a breaktrace threshold of 150 microseconds so that if we terminate the run early, I'll have an ftrace file I can use narrow down on what's causing latency spikes.


Attachment: pgp0hTETJFIYH.pgp
Description: OpenPGP digital signature