Message-ID: <20110221211352.GA3583@nowhere>
Date:	Mon, 21 Feb 2011 22:13:55 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	David Ahern <daahern@...co.com>
Cc:	Ingo Molnar <mingo@...e.hu>, linux-perf-users@...r.kernel.org,
	linux-kernel@...r.kernel.org, peterz@...radead.org,
	acme@...stprotocols.net, paulus@...ba.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Arnaldo Carvalho de Melo <acme@...hat.com>
Subject: Re: [PATCH 3/3] perf events: add timehist option to record and
 report

On Fri, Feb 18, 2011 at 12:53:34PM -0700, David Ahern wrote:
> 
> 
> On 02/18/11 12:24, Frederic Weisbecker wrote:
> >> We want not only context-switch events, but the stack trace at the
> >> switch. For example, with the stack trace you can see preemption -- when
> >> a process got booted by another and where the booted process is at the
> >> time. You can see not only which system call caused an ap to block
> >> (e.g., an ioctl) but the full code path leading to the block.
> > 
> > You can recognize preemption a the context switch tracepoint: if the state
> > of the scheduled out task is R (TASK_RUNNING), which means it doesn't go
> > to sleep but gets preempted, with an explicit preemption point like cond_resched(),
> > or a more implicit one: spin_unlock(), preempt_enable(), an interrupt, ...
> > Or it has been woken up while it was about to sleep, but it doesn't make much
> > difference.
> > 
> > If you want to know when a process is booted by another you can use the
> > fork tracepoint, or sched:wake_up_new, etc...
> > 
> > And you can use syscall tracepoints to get the syscalls you want.
> > 
> > I don't see much the point for you to use stacktraces. But if you
> > do, then rather add this support to perf script, in our scripting
> > framework.
> 
> It's more the simplicity of what we are using today. 1 command, 1 event
> being monitored:
> 
>   perf record -ag -e cs -c 1
> 
> A wealth of information. That command shows preemption, stack traces
> only for context-switches (not all of the syscalls which is
> overwhelming) and opens the door for other analysis. One data set.
> Simple. Focused.

Right. Then why not adding support to stacktraces in perf script?
Seems it's the only missing thing to achieve what you want.

> > Because what you've done is basically to add tracing support to
> > perf report. But we have perf script for that already. It only focuses
> > on tracepoint events but they are those people are interested in
> > because they show logical events in the kernel. I guess
> > people are not interested in cpu-cycles overflows events or so as
> > they don't show a state change in the kernel.
> 
> I have always referred to this as pretty printing each sample recorded
> as opposed to summarizing into a histogram. With that approach you have
> dictated the analysis of the data - a histogram summary. By printing
> each sample with address-symbol conversions we can look at it in
> whatever angle we need to make sense of it.

I'm not dictating any analysis. You can can just launch
perf script without script and it will display the events,
like you want.

Just try:

perf record -a -e sched:sched_switch
perf script

You can extend it to print addresses or symbols or even stacktraces.
It just seems to me the right place to do so. Not perf report that is
about histograms.
--
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