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

[Clark Williams]

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. 

Clark

Attachment: pgp0hTETJFIYH.pgp
Description: OpenPGP digital signature