From: "Liang, Kan" <kan.liang@linux.intel.com>
To: Stephane Eranian <eranian@google.com>
Cc: Andi Kleen <ak@linux.intel.com>,
linux-kernel@vger.kernel.org, peterz@infradead.org,
kan.liang@intel.com, acme@redhat.com, namhyung@kernel.org,
irogers@google.com
Subject: Re: [PATCH] perf/x86/intel/lbr: fix branch type encoding
Date: Mon, 15 Aug 2022 16:39:13 -0400 [thread overview]
Message-ID: <23f552cd-8350-5258-331f-f24236d6d322@linux.intel.com> (raw)
In-Reply-To: <CABPqkBQS+CUB2TJs4xcHPq+ymr3=OCwxa2pamtLR+r5AyBsmKQ@mail.gmail.com>
On 2022-08-15 3:45 p.m., Stephane Eranian wrote:
> On Sun, Aug 14, 2022 at 12:37 PM Liang, Kan <kan.liang@linux.intel.com> wrote:
>>
>>
>>
>> On 2022-08-12 4:16 a.m., Andi Kleen wrote:
>>>
>>>>
>>>> I think the option is to avoid the overhead of disassembling of branch
>>>> instruction. See eb0baf8a0d92 ("perf/core: Define the common branch type
>>>> classification")
>>>> "Since the disassembling of branch instruction needs some overhead,
>>>> a new PERF_SAMPLE_BRANCH_TYPE_SAVE is introduced to indicate if it
>>>> needs to disassemble the branch instruction and record the branch
>>>> type."
>>>
>>>
>>> Thanks for digging it out. So it was only performance.
>>>
>>>>
>>>> I have no idea how big the overhead is. If we can always be benefit from
>>>> the branch type. I guess we can make it default on.
>>>
>>> I thought even arch LBR had one case where it had to disassemble, but
>>> perhaps it's unlikely enough because it's pre filtered. If yes it may be
>>> ok to enable it there unconditionally at the kernel level.
>>>
>>
>> Yes, Arch LBR should have much less overhead than the previous
>> platforms. The most common branches, JCC and near JMP/CALL, are from the
>> HW. Only the other branches, e.g., far call, SYS* etc, which still rely
>> on the SW disassemble. The number of the other branches should not be
>> big. I agree that we should enable the branch type for the Arch LBR
>> unconditionally at the kernel level.
>>
>> Peter? Stephane? What do you think?
>>
>>> Still have to decide if we want older parts to have more overhead by
>>> default. I guess would need some data on that.
>>
> I don't think you want that. It is okay to have it when it is free. Otherwise it
> is best if it remains opt-in.>>
>> The previous LBR already has high overhead. The branch type overhead
>> will make it worse. I think it's better keep it default off. I think we
>> can make it clear in the document that the branch type is only default
>> on for the new platforms with Arch LBR support (12th-Gen+ client or
>> 4th-Gen Xeon+ server).
>>
> I am okay with that.
I see.
I will post a kernel patch to enable the branch type for Arch LBR by
default, and also update the perf tool document as Arnaldo suggested.
Thanks,
Kan
next prev parent reply other threads:[~2022-08-16 0:43 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-10 21:06 [PATCH] perf/x86/intel/lbr: fix branch type encoding Stephane Eranian
2022-08-11 12:23 ` Liang, Kan
2022-08-11 14:17 ` Stephane Eranian
2022-08-11 14:41 ` Liang, Kan
2022-08-11 15:28 ` Stephane Eranian
2022-08-11 15:33 ` Stephane Eranian
2022-08-11 15:56 ` Liang, Kan
2022-08-12 8:16 ` Andi Kleen
2022-08-14 19:37 ` Liang, Kan
2022-08-15 19:45 ` Stephane Eranian
2022-08-15 20:39 ` Liang, Kan [this message]
2022-08-12 19:35 ` Arnaldo Carvalho de Melo
2022-08-14 19:39 ` Liang, Kan
2022-08-11 20:21 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=23f552cd-8350-5258-331f-f24236d6d322@linux.intel.com \
--to=kan.liang@linux.intel.com \
--cc=acme@redhat.com \
--cc=ak@linux.intel.com \
--cc=eranian@google.com \
--cc=irogers@google.com \
--cc=kan.liang@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.