lkml.org 
[lkml]   [2011]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH -tip v3 0/6] perf: Introduce branch sub commands
    On Fri, Apr 01, 2011 at 07:57:05PM +0900, Akihiro Nagai wrote:
    > (2011/03/30 23:46), Frederic Weisbecker wrote:
    > <snip>
    > >>'perf branch trace' can parse and analyze recorded BTS log and print various
    > >>information of execution path. This command can show address, pid, command name,
    > >>function+offset, file path of elf.
    > >>You can choose the printed information with option.
    > >>
    > >>Example: 'perf branch trace'
    > >>function+offset
    > >>irq_return+0x0 => _start+0x0
    > >>irq_return+0x0 => _start+0x0
    > >>_start+0x3 => _dl_start+0x0
    > >>irq_return+0x0 => _dl_start+0x0
    > >>irq_return+0x0 => _dl_start+0x26
    > >>irq_return+0x0 => _dl_start+0x2d
    > >
    > >These results are a bit surprising. May be we can
    > >jump once from irq_return to _start, in the first schedule()
    > >of a new task perhaps, but thereafter I would expect
    > >further jumps not to happen from irq_return, but rather
    > >from _start. When we have x as a destination in line n, then
    > >I would expect to have x as a source in n + 1.
    > Agree with the opinion "irq_start" surprising users.
    > However, I think it is not a better solution that uses a
    > previous destination as a next source.
    > Because, users want to know what happen in userspace and,
    > do not want to know interrupts from kernel.
    >
    > I think the better solution is to implement the filter that
    > eliminate the record including kernel functions from output.

    Yep.

    > For example, leading example will be filtered like this.
    >
    > _start+0x3 => _dl_start+0x0
    >
    > In the future, I think the solution is available that using BTS records
    > with trace event like irq:irq_handler_entry to analyze interrupt.
    > However, to do it, we need to fix perf.

    Right.

    > >
    > >Also we are supposed to only trace BTS in userspace, but
    > >perhaps, if we are interrupted, after the execution of the iret instruction,
    > >BTS considers the following jump "iret -> interrupted inst" as a branch
    > >in userspace. After all it makes sense, it is a jump in userspace.
    > >
    > >So BTS, because of the way it defines a jump inside userspace,
    > >traces irq returns but not irq entries, that would explain the trace
    > >you gave as an example.
    > >
    > >I suspect we want to filter irq returns. ie: if the source comes
    > >from the kernel, then filter it by default. And then we can later
    > >think about an option to enable interrupt return tracing if
    > >people want them.
    > Agree.
    > I will implement the option that enable/disable the filter.

    Cool, thanks!


    \
     
     \ /
      Last update: 2011-04-01 14:55    [W:2.785 / U:0.040 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site