Re: [PATCH 00/14] perf c2c: add a function view

[Jiebin Sun]

Hi Namhyung,

Thank you, and thanks for the idea.

> On Fri, Jul 10, 2026 at 04:49:20PM +0800, Jiebin Sun wrote:
> > > Any chance it can share the code?  We have `perf mem report` as well,
> > > which deals with similar kind of data.
> >
> > The part it does not reuse is the generic report hierarchy builder. That
> > nests a single sample's own sort keys, while the function view pairs
> > functions that share a cacheline -- the entries are (function A,
> > function B) pairs that don't map to one sample. That's why the hierarchy
> > is built explicitly rather than from a sort-key list.
>
> I see.  Yeah I think it's a different model but it may be possible to
> have a cacheline in a parent node and functions that accessed it in
> the children.

You're right that a cacheline-parent / accessing-functions-children
layout maps cleanly onto a single sample's own keys, so that one could be
expressed with the generic hierarchy (e.g. sorting on dcacheline then
symbol).

That organization is cacheline-centric, and fairly close to what the
cacheline view already offers -- the cacheline list, and the
per-cacheline detail ('d') that lists the accesses and the symbols
touching a given cacheline.

The function view is function-centric instead: starting from a function
and showing which other functions it contends with, and over which
cachelines. That "which functions contend with each other" pairing is
what needs the explicit build rather than a sort-key list.

Aggregating by function also helps to rank functions by their total HITM
penalty (HITM count times per-access latency). The cacheline view shows
the per-access HITM percentages and the latency, but not that product
summed per function.

A real false-sharing case we are working on is a good example. One of the
functions involved, cpupri_set, has its accesses split across several
cachelines, and within any single cacheline each access is only a small
share of that line's HITM (a few percent per access), so it doesn't stand
out in the per-cacheline view. Its cost only becomes apparent once summed
across the cachelines it touches, which is what the function view does --
it surfaces as a top per-function entry and points straight at the
function to investigate, without the user piecing it together across
cachelines by hand.

  https://lore.kernel.org/all/cover.1753076363.git.pan.deng@xxxxxxxxx/

Thanks,
Jiebin