lkml.org 
[lkml]   [2011]   [Feb]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 3/3] perf events: add timehist option to record and report


    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.

    >
    > 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.

    David


    >
    > Well, yeah I can understand if one considers the software events,
    > that makes meaningful events from the kernel. But these software events
    > support have been a mistake in perf. You should rather use the
    > tracepoint events instead.
    >
    >> That data along with the gettimeofday timestamp has allowed us to
    >> resolve performance issues such as a system call taking longer than
    >> expected during a specific sequence of events or a process getting
    >> preempted and not scheduled for N seconds. etc., etc.
    >
    > That's about the same here. If you really need this, you need to add
    > the support in perf script to handle that on tracepoint events.
    > --
    > To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
    > the body of a message to majordomo@vger.kernel.org
    > More majordomo info at http://vger.kernel.org/majordomo-info.html


    \
     
     \ /
      Last update: 2011-02-18 20:57    [W:0.032 / U:0.056 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site