Messages in this thread | | | Date | Fri, 01 Apr 2011 19:57:05 +0900 | From | Akihiro Nagai <> | Subject | Re: [PATCH -tip v3 0/6] perf: Introduce branch sub commands |
| |
(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. 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.
> > 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.
> > Thanks. Thank you for your advise.
| |