Date:	Wed, 16 Jan 2008 15:49:16 -0500 (EST)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
cc:	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Christoph Hellwig <hch@...radead.org>,
	Gregory Haskins <ghaskins@...ell.com>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	Tim Bird <tim.bird@...sony.com>,
	Sam Ravnborg <sam@...nborg.org>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Steven Rostedt <srostedt@...hat.com>,
	Paul Mackerras <paulus@...ba.org>,
	Daniel Walker <dwalker@...sta.com>
Subject: Re: [RFC PATCH 16/22 -v2] add get_monotonic_cycles


On Wed, 16 Jan 2008, Mathieu Desnoyers wrote:
> >
> > In-other-words, latency_tracer is LTTng-lite ;-)
> >
>
> If LTTng is already ported to your specific kernel, the learning-curve
> is not big at all. Here is what the latency_tracer over LTTng guide
> could look like :
>
> Well, once you have LTTng in your kernel and have compiled and installed
> the ltt-control and lttv packages (configure, make, make install), all
> that would be needed is :
>
> (there may be some bits in the QUICKSTART GUIDE on
> http://ltt.polymtl.ca, like adding the debugfs mount to fstab and make sure
> the LTTng modules are loaded)
>
> #arm all the markers
> ltt-armall
> #start lttng tracing
> lttctl -n test -t /tmp/trace1 -d -l /mnt/debugfs/ltt
>
> -> start latency tracer
> -> stop latency tracer
> -> trigger latency tracer dump
>
> While the tracing is active, trigger the condition...
>
> (rince, repeat, can handle multiple latency tracer dumps)
>
> #stop lttng tracing
> lttctl -n test -R
> #disarm all markers
> ltt-disarmall
>
> You can easily test the trace with :
> lttv -m textDump -t /tmp/trace1
>
> Your users would issue something like :
>
> lttv -m latencytracerDump -t /tmp/trace1
>
> that's it. LatencytracerDump would be a new specialized plugin, inspired
> from the generic textDump.c plugin and from the state.c module (for
> hooking on specific events rather that on _all_ events). It would
> generate a text output from the trace collected at each latency tracer
> dump.
>

Mathieu,

That's quite a bit. Currently we have tools that already hook into
latency_tracer. e.g. Thomas Gleixner's cyclictest. It turns on the latency
tracer runs a quick test, turns it off. If the latency is ok, the trace is
discarded and it runs the test again. When the latency is not acceptable,
it stops the test. Then all one needs to do is look at the given trace.

Hooking something simple as this to LTTng is not going to fly.

Don't get me wrong, I'm a huge supporter of LTTng, and even recommend it.
But there's things that using LTTng for is like using a sledgehammer for
a tack.  I like to use the tools that are best for the job (which also
mean easiest).  I don't buy the one tracer fits all mentality. And by
pushing that too much, I'm thinking we'll never get a tracer into the
kernel.

What my goal of these patches is, is to get the infrastructure for tracing
into the kernel.  The latency_tracer is like Rusty Russells lguest is for
pvops. LTTng is the Xen equivalent. Where latency_tracer is nothing more
than the quick and dirty tracer. For administrators that want to analyze
their systems, LTTng is much more appropriate. latency_tracer is more of
the first aid in finding latency troubles, and if that doesn't work, then
we can do the LTTng surgery.

Lets go back and focus on the infrastructure again. Namely, the mcount and
notrace parts of the kernel. As well as the tracer timer, which by the
way, we are looking more into what you have done ;-)

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists