[lkml]   [2011]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH -tip v3 0/6] perf: Introduce branch sub commands
    On Thu, Mar 24, 2011 at 08:31:37PM +0900, Akihiro Nagai wrote:
    > Hi,
    > This patch series provides the commands 'perf branch record' and 'perf branch trace'
    > version 3. These commands record and analyze a BTS (Branch Trace Store) log.
    > And, they provide the interface to use BTS log for application developers.
    > BTS is a facility of Intel x86 processors, which records the address of
    > 'branch to/from' on every branch/jump instruction and interrupt.
    > This facility is very useful for developers to test their software,
    > for example, coverage test, execution path analysis, dynamic step count ...etc.
    > These test tools have a big advantage, which user doesn't have to modify target
    > executable binaries, because the BTS is a hardware feauture.
    > But, there are few applications using BTS. Reasons I guess are ...
    > - Few people know what BTS is.
    > - Few people know how to use BTS on Linux box.
    > - It's hard to analyze the BTS log because it includes just a series of addresses.
    > So, I want to provide a user-friendly interface to BTS for application developers.
    > About new sub commands
    > ========================
    > 'perf branch record' provides an easy way to record BTS log.
    > Usage is 'perf branch record <command>'. This command is just an alias to
    > 'perf record -e branches:u -c 1 <command>'. But, new one is more simple and
    > more intuitive.
    > '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.

    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.


     \ /
      Last update: 2011-03-30 16:49    [W:0.024 / U:46.084 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site