[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZrLoeSR_U26ASD0T@tassilo>
Date: Tue, 6 Aug 2024 20:22:33 -0700
From: Andi Kleen <ak@...ux.intel.com>
To: Namhyung Kim <namhyung@...nel.org>
Cc: "Liang, Kan" <kan.liang@...ux.intel.com>, acme@...nel.org,
irogers@...gle.com, peterz@...radead.org, mingo@...nel.org,
linux-kernel@...r.kernel.org, adrian.hunter@...el.com,
eranian@...gle.com
Subject: Re: [PATCH 6/9] perf report: Display the branch counter histogram
> I understand your point. But I think we need to provide an easily
> parse-able format at least for CSV output.
It's easily parseable, e.g. in python:
>>> collections.Counter(re.findall(r'[A-Z][0-9]?', "AAAB"))
Counter({'A': 3, 'B': 1})
>
> >
> > I don't think there is a plan to increase the saturation of the counter.
> > So 4 bits of width should last for a long time. Other ARCHs don't have
> > such a feature either. I think I can the change the code to force the 4
> > bits of width now. For more that 3 events, the perf tool can convert it
> > to a "+". We may update the perf tool for a more specific histogram
> > later, if the saturation is changed. What do you think?
>
> Ok, 4 bits width is probably fine. How many events can a LBR entry
> support? Maybe that's limited by the number of HW counters but
> theoretically 64 / 4 = 16, right?
The MSR doesn't have that many free bits. It's limited to 4 events.
-Andi
Powered by blists - more mailing lists