linux-kernel - Re: [PATCH 2/6] perf: Support branch events logging

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2428e6a2-9578-1e1d-bdef-ffcc87301503@linux.intel.com>
Date:   Fri, 14 Apr 2023 16:34:45 -0400
From:   "Liang, Kan" <kan.liang@...ux.intel.com>
To:     Peter Zijlstra <peterz@...radead.org>,
        Andi Kleen <ak@...ux.intel.com>
Cc:     mingo@...hat.com, acme@...nel.org, linux-kernel@...r.kernel.org,
        mark.rutland@....com, alexander.shishkin@...ux.intel.com,
        jolsa@...nel.org, namhyung@...nel.org, irogers@...gle.com,
        adrian.hunter@...el.com, eranian@...gle.com
Subject: Re: [PATCH 2/6] perf: Support branch events logging



On 2023-04-14 3:24 p.m., Peter Zijlstra wrote:
> On Fri, Apr 14, 2023 at 01:53:24PM -0400, Liang, Kan wrote:
>>
>>
>> On 2023-04-14 12:09 p.m., Peter Zijlstra wrote:
>>> On Fri, Apr 14, 2023 at 11:56:41AM -0400, Liang, Kan wrote:
>>>>> If it were to only support 4, then
>>>>> we're in counter scheduling contraint hell again 
>>>>
>>>> Unfortunately, yes.
>>>>
>>>>> and we need to somehow
>>>>> group all these things together with the LBR event.
>>>>
>>>> Group will bring many limits for the usage. For example, I was told
>>>> there could be someone wants to use it with multiplexing.
>>>
>>> You can create two groups, each with an LBR event, no?
>>
>> If we put everything in a group, that will make the enabling much
>> simpler. I don't think the perf tool needs the order information
>> anymore. Because the kernel enables the events one by one in a group.
>> The kernel just need to convert the information from the counter order
>> to the enabling order and dump to user space.
> 
> I never understood the whole order thing. What was it trying to do?

Let's say we have three events with the LBR event logging feature as below.
    perf record -e branches,branches,instructions:ppp -j any,event

The counter 0 will be assigned to instructions:ppp, since the PDist is
only supported on GP 0 & 1.
The count 1 & 2 will be assigned to the other two branches.

If branches occurs 1 time and instructions occurs 3 times in a LBR
block, the LBR_INFO will have 0b010111 (counter order).

But as you can see from the perf command, the first event is actually
branches. Without the event IDs information, perf tool will interpret
that branches 3 branches 1 and instructions:ppp 1. That's wrong.

If there are multiple users, the situation becomes even worse.

> 
>> But if we have two groups with LBR event, the order information is still
>> required. Why we still want to group things?
> 
> Why would you need that; what is that whole order nonsense about?
> 
> {e1, e2, e3, e4}, {e5, e6, e7, e8} with e1 and e5 both having LBR on
> just works no?
> 
> Since they have LBR and that extra sample flag they all get a 0-3
> constraint.
> 
> Since both e1 and e5 use LBR, they're mutually exclusive, either e1 or
> e5 group runs.

It's possible that someone pins an event using LBR, and set more than 4
events for logging, e0:D,{e1, e2},{e3, e4},{e5, e6}. If so, those events
could do multiplexing. Without the event IDs information, perf tool has
no idea how to interpret the information.


Andi, do you have any other cases which require the multiplexing support
for LBR event logging.


Thanks,
Kan