[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <57af142d-92d0-5d0f-1ddb-f27f122ae752@linux.intel.com>
Date: Thu, 6 Apr 2017 22:43:19 +0800
From: "Jin, Yao" <yao.jin@...ux.intel.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Arnaldo Carvalho de Melo <acme@...nel.org>,
Jiri Olsa <jolsa@...nel.org>, linux-kernel@...r.kernel.org,
ak@...ux.intel.com, kan.liang@...el.com, yao.jin@...el.com,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH v1 1/5] perf/core: Define the common branch type
classification
On 4/6/2017 5:25 PM, Peter Zijlstra wrote:
> On Thu, Apr 06, 2017 at 04:21:06PM +0800, Jin, Yao wrote:
>> Hi, otherwise we have to maintain 2 branch type copies between kernel and
>> user-space.
>>
>> For example, currently X86_BR_* are defined in lbr.c. To display the branch
>> type in user-space, the user-space has to maintain the same copy for
>> X86_BR_*. I didn't get a better idea.
> I still don't understand what you want; or why it would matter.
>
> Those specific macros are for hardware LBR filter emulation/fixup. What
> does that have to do with any userspace crud?
I just want to provide a new feature that the user can directly check
branch type
in perf report, instead of looking it up in the binary. Binary could be
not available
later, so it's possible that userspace can't get the branch type.
The X86_BR are generated when disassembling the branch instruction in
kernel.
They can be considered as the x86 branch types.
It's easy to let kernel return the x86 branch types to userspace, and
then userspace
shows the branch type in perf report.
While kernel and userspace have to maintain the X86_BR definitions. One
copy is in
kernel and the other copy is in userspace. To avoid the duplicate
definitions , I define
the common branch type in perf_event.h to share between kernel and
userspace.
That's why I do that.
Thanks
Jin Yao
Powered by blists - more mailing lists