Messages in this thread | | | Date | Wed, 30 Mar 2011 16:46:43 +0200 | From | Frederic Weisbecker <> | Subject | Re: [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.
Thanks.
| |