public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: "Liang, Kan" <kan.liang@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>,
	mingo@redhat.com, acme@kernel.org, linux-kernel@vger.kernel.org,
	mark.rutland@arm.com, alexander.shishkin@linux.intel.com,
	jolsa@kernel.org, namhyung@kernel.org, irogers@google.com,
	adrian.hunter@intel.com, eranian@google.com
Subject: Re: [PATCH 2/6] perf: Support branch events logging
Date: Sat, 15 Apr 2023 00:01:06 +0200	[thread overview]
Message-ID: <20230414220106.GC778423@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <2428e6a2-9578-1e1d-bdef-ffcc87301503@linux.intel.com>

On Fri, Apr 14, 2023 at 04:34:45PM -0400, Liang, Kan wrote:

> > 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 this makes no sense what so ever; in this case you have no control
over what events you'll actually get in your LBR. Could be none of the
events you're interested in end up in 0-3 but instead land on 4-7.

> >> 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.

Yeah, don't do this. There is no guarantee what so ever you'll get any
of those events in the 0-3 range.

You really *must* make then a group such that perf knows what events to
associated with the LBR event and constain them to the 0-3 range of
PMCs.

If you want multiplexing, simply create multiple groups with an LBR
event in them.

  reply	other threads:[~2023-04-14 22:01 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-10 20:43 [PATCH 1/6] perf/x86/intel: Add Grand Ridge and Sierra Forest kan.liang
2023-04-10 20:43 ` [PATCH 2/6] perf: Support branch events logging kan.liang
2023-04-14 10:38   ` Peter Zijlstra
2023-04-14 13:35     ` Liang, Kan
2023-04-14 14:53       ` Peter Zijlstra
2023-04-14 15:56         ` Liang, Kan
2023-04-14 16:09           ` Peter Zijlstra
2023-04-14 17:53             ` Liang, Kan
2023-04-14 19:24               ` Peter Zijlstra
2023-04-14 20:34                 ` Liang, Kan
2023-04-14 22:01                   ` Peter Zijlstra [this message]
2023-04-14 22:47                     ` Andi Kleen
2023-04-17 11:46                       ` Peter Zijlstra
2023-04-17 13:37                         ` Andi Kleen
2023-04-17 14:07                           ` Liang, Kan
2023-04-17 11:55                       ` Peter Zijlstra
2023-04-17 13:41                         ` Andi Kleen
2023-04-10 20:43 ` [PATCH 3/6] perf/x86/intel: Support LBR event logging kan.liang
2023-04-10 20:43 ` [PATCH 4/6] tools headers UAPI: Sync include/uapi/linux/perf_event.h header with the kernel kan.liang
2023-04-10 20:43 ` [PATCH 5/6] perf tools: Add branch event knob kan.liang
2023-04-10 20:43 ` [PATCH 6/6] perf tools: Support PERF_SAMPLE_BRANCH_EVENT_IDS kan.liang

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=20230414220106.GC778423@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=eranian@google.com \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=kan.liang@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox