Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1755717Ab1DAK5M (ORCPT <rfc822;w@1wt.eu>);
	Fri, 1 Apr 2011 06:57:12 -0400
Received: from mail9.hitachi.co.jp ([133.145.228.44]:37985 "EHLO
	mail9.hitachi.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1755492Ab1DAK5L (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 1 Apr 2011 06:57:11 -0400
X-AuditID: b753bd60-a20f6ba000000ee4-01-4d95af842428
X-AuditID: b753bd60-a20f6ba000000ee4-01-4d95af842428
Message-ID: <4D95AF81.5050306@hitachi.com>
Date: Fri, 01 Apr 2011 19:57:05 +0900
From: Akihiro Nagai <akihiro.nagai.hw@hitachi.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Arnaldo Carvalho de Melo <acme@infradead.org>, Ingo Molnar <mingo@elte.hu>,
        Peter Zijlstra <peterz@infradead.org>, linux-kernel@vger.kernel.org,
        Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
        2nddept-manager@sdl.hitachi.co.jp, David Ahern <daahern@cisco.com>
Subject: Re: [PATCH -tip v3 0/6] perf: Introduce branch sub commands
References: <20110324113137.20235.42265.stgit@localhost6.localdomain6> <20110330144639.GA2204@nowhere>
In-Reply-To: <20110330144639.GA2204@nowhere>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2589
Lines: 63

(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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/