Re: [PATCH v1 4/7] perf tools: Expose opt-in --hybrid-merge

Re: [PATCH v1 4/7] perf tools: Expose opt-in --hybrid-merge

[Arnaldo Carvalho de Melo]

On Mon, Aug 24, 2026 at 08:33:02PM -0700, Ian Rogers wrote:
> On Mon, Aug 24, 2026 at 3:40 PM Andi Kleen <andi@firstfloor.org> wrote:
> > On Sun, Aug 23, 2026 at 11:37:41PM -0700, Ian Rogers wrote:
> > > Add --hybrid-merge flag to explicitly trigger event merging
> > > non-interactively
> > > for both perf-top and perf-report.

> > Well it should be default on.

> > I don't want another option I have to always specify like
> > --no-children.

Picking defaults is difficult...

Linus doesn't like the buildid cache, so he can pick something different
than the default of saving binaries that will be useful immediately
after when doing annotation, etc.

I don't like having to specify --no-children either, but lots of people
like it.
 
> I agree we should be able to change defaults. Just over 2 years ago, I sent out:
> https://lore.kernel.org/linux-perf-users/20240516222159.3710131-1-irogers@google.com/
> That switches the histogram behavior in perf top to zero after every
> refresh rather than decaying the values. If you filter perf top by

See? Ian has his preferences, like Andi, how come?

> user, it can be common to get no samples. Note that around this time,
> we fixed this behavior to work really nicely by using BPF instead of
> horrible /proc scanning. In the default decay mode, a symbol that ran
> in the past will appear in perf top even if the process with that
> symbol has terminated. This happens frequently in user mode, resulting
> in many ghost symbols and lingering processes. The zero mode, which
> ironically matches top's behavior, isn't the default because it would
> be a noticeable change in the defaults.
 
> Anyway, this is a long winded way of saying that Namhyung and Arnaldo
> pick the defaults. I didn't choose to change the defaults in this

I wish I could pick defaults wisely (or that the maintainer du jour do
it), its a hard call, and when I _do_ pick some default eventually I end
up very disappointed with myself when I find out that my thinking was
flawed.

> series because I think if you test the changes, you'll see that
> hitting 'M' at startup really isn't that much of a chore and it gives
> a clear signal that you are doing something special. Perf top also
> hints at the 'M' key along the bottom of the screen when hybrid events
> are present. If this is too much to live with, I think we could make

I don't think this is too much to live with and I I like being able to
have this switch, perhaps having a "do it permanently" after one thinks
it is the right default, should be made available.

> it a config file value. I think this matches the principle of least
> surprise, while the decay mode default, I'd argue, is the opposite.

This hybrid situation is one that is indeed a source of way too many
problems with how to properly aggregate counters from different types of
cores, having a way to go back and forth from aggregated (taking into
account freqs and whatnot) and the current per event type, which is
utterly sub-optimal for a system wide view seems to be an improvement.

Doing it just for cycles seems a step in the right direction, doing it
in a way that takes into account all types of events seems like a worthy
goal, lets make some sort of progress here with, I think, Ian's attempt
at taking into account all sorts of events while making the simple case
Andi cares to work, can we go with that?

- Arnaldo