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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 3 May 2016 15:28:39 -0500
From:	Clark Williams <williams@...hat.com>
To:	Luiz Capitulino <lcapitulino@...hat.com>
Cc:	John Kacur <jkacur@...hat.com>,
	RT <linux-rt-users@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] cyclictest: stop any tracing after hitting a breaktrace
 threshold

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

> On Tue, 3 May 2016 12:59:53 -0500
> Clark Williams <williams@...hat.com> 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

Content of type "application/pgp-signature" skipped