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:

quoted

quoted

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.

quoted

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.