From: Jiebin Sun <jiebin.sun@intel.com>
To: Namhyung Kim <namhyung@kernel.org>
Cc: acme@kernel.org, mingo@redhat.com, peterz@infradead.org,
adrian.hunter@intel.com, alexander.shishkin@linux.intel.com,
irogers@google.com, james.clark@linaro.org, jolsa@kernel.org,
mark.rutland@arm.com, dapeng1.mi@linux.intel.com,
thomas.falcon@intel.com, tianyou.li@intel.com,
wangyang.guo@intel.com, linux-perf-users@vger.kernel.org,
linux-kernel@vger.kernel.org, Jiebin Sun <jiebin.sun@intel.com>
Subject: [PATCH v5 v5 9/9] perf c2c: document function view in perf-c2c man page
Date: Thu, 30 Jul 2026 17:05:21 +0800 [thread overview]
Message-ID: <20260730090521.2206375-10-jiebin.sun@intel.com> (raw)
In-Reply-To: <20260730090521.2206375-1-jiebin.sun@intel.com>
Describe the function view hierarchy (read-side function -> contending
writer function -> shared cachelines), the per-level indentation, and the
keys, with a worked example.
Document that reliable function attribution requires `iaddr` in
`--coalesce`, that the reader and writer may be the same function, and why
the coalesced function view cannot distinguish same-thread from
different-thread accesses in that case. Also document that verbose mode
includes code addresses in function rows.
Signed-off-by: Jiebin Sun <jiebin.sun@intel.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Dapeng Mi <dapeng1.mi@linux.intel.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: James Clark <james.clark@linaro.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Falcon <thomas.falcon@intel.com>
Reviewed-by: Tianyou Li <tianyou.li@intel.com>
Reviewed-by: Wangyang Guo <wangyang.guo@intel.com>
---
tools/perf/Documentation/perf-c2c.txt | 71 +++++++++++++++++++++++++++
1 file changed, 71 insertions(+)
diff --git a/tools/perf/Documentation/perf-c2c.txt b/tools/perf/Documentation/perf-c2c.txt
index e57a122b8719..8775889bc0a3 100644
--- a/tools/perf/Documentation/perf-c2c.txt
+++ b/tools/perf/Documentation/perf-c2c.txt
@@ -365,6 +365,77 @@ TUI OUTPUT
The TUI output provides interactive interface to navigate
through cachelines list and to display offset details.
+Pressing the 'TAB' key in the cacheline view switches to the function
+view. The function view shows a three-level hierarchy of the symbolized
+entries retained in the cacheline view, organized around functions rather
+than cachelines. Levels 1 and 2 normally show function names, while level 3
+shows cacheline addresses. Lower levels are indented beneath their parents.
+Verbose mode also includes code addresses in function rows, and code addresses
+remain available in the per-cacheline detail view ('d').
+
+The function view requires `iaddr` in the cacheline coalescing fields. If
+`--coalesce` omits it, TAB reports that the view is unavailable rather than
+attributing already-coalesced samples to an arbitrary function.
+
+ Level 1: the read-side function, sorted by Cycles % (estimated load
+ cycles: HITM, peer-snoop and other-load cycles)
+ Level 2: the functions sampled writing the shared lines read by the
+ level-1 function, sorted by store count. This can be the same
+ function when it has both read and write samples
+ Level 3: the specific cachelines shared by the reader/writer pair
+
+The Cycles % value is the function's share of event-provided load
+latency/weight estimates from cacheline-detail entries retained in the
+current view. It can include non-HITM and non-peer loads coalesced into
+entries that pass the C2C filter, so it is not a pure contention-cycle
+percentage. The share is relative to the functions and entries retained
+for the current report and is not comparable across recordings or different
+`--coalesce` settings.
+
+The store count on a level-1 row is the number of sampled stores by writers
+shown in the function view into the cachelines that function reads, including
+stores from the same function. It decomposes into the level-2 writer rows;
+each level-2 count in turn decomposes into that writer's stores on its level-3
+cachelines. A level-3 count is therefore not the cacheline's total store
+count. The level-1 value is not the number of stores made by the reader and
+is not additive across level-1 rows: two functions reading the same line each
+carry the stores into that line.
+
+Each function aggregates all of its code addresses into a single entry,
+and a level-2 writer aggregates all of its shared cachelines, so a
+reader/writer pair is a single row with its total shown -- there is no
+need to sum a writer's traffic across cachelines by hand.
+
+In the function view the 'd' key opens the detail view of the selected
+level-3 cacheline, 'e'/'+' expands or collapses the current entry, and 'TAB',
+'ESC', 'q' or Ctrl-C returns to the cacheline view.
+
+For example, with the first two read-side functions collapsed and
+dequeue_pushable_task expanded to show the functions writing the lines it
+reads -- two of which are further expanded to their individual cachelines:
+
+ Shared Data Functions Table (19 entries, sorted on Cycles %)
+ Cycles Store
+ % count Function / Contending function / Cacheline
+ ----------------------------------------------------------------------
+ + 35.67% 876 + [k] cpupri_set
+ + 24.31% 424 + [k] pull_rt_task
+ - 16.53% 555 - [k] dequeue_pushable_task
+ 145 - [k] pull_rt_task
+ 145 0xff2d0082809da080
+ 139 - [k] enqueue_pushable_task
+ 70 0xff2d00a2071f9640
+ 69 0xff2d0082809da000
+
+Here dequeue_pushable_task pays 16.53% of the estimated read-side load-cycle
+cost. Its store count decomposes into its level-2 writers, and each writer's
+count decomposes into its level-3 cachelines: pull_rt_task's 145 stores fall
+on a single line, while enqueue_pushable_task's 139 stores split across two
+lines (70 and 69). A writer can be the same function as the reader when it
+has both read and write samples; after cacheline coalescing and
+function-level grouping, the view cannot distinguish same-thread accesses
+from different threads running the same function.
+
For details please refer to the help window by pressing '?' key.
CREDITS
--
2.52.0
prev parent reply other threads:[~2026-07-30 9:01 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-30 9:05 [PATCH v5 0/9] perf c2c: add a function view Jiebin Sun
2026-07-30 9:05 ` [PATCH v5 v5 1/9] perf c2c: extract shared data structures into c2c.h Jiebin Sun
2026-07-30 9:13 ` sashiko-bot
2026-07-30 9:05 ` [PATCH v5 v5 2/9] perf c2c: add function view browser skeleton Jiebin Sun
2026-07-30 9:05 ` [PATCH v5 v5 3/9] perf c2c: add column rendering for function view Jiebin Sun
2026-07-30 9:05 ` [PATCH v5 v5 4/9] perf c2c: add HPP list parsing for function view columns Jiebin Sun
2026-07-30 9:05 ` [PATCH v5 v5 5/9] perf c2c: add function view stats merge and memory management Jiebin Sun
2026-07-30 9:05 ` [PATCH v5 v5 6/9] perf c2c: add function view hierarchy entry creation Jiebin Sun
2026-07-30 9:19 ` sashiko-bot
2026-07-30 9:05 ` [PATCH v5 v5 7/9] perf c2c: build and finalize the function view hierarchy Jiebin Sun
2026-07-30 9:05 ` [PATCH v5 v5 8/9] perf c2c: add function view browser UI and cacheline detail Jiebin Sun
2026-07-30 9:30 ` sashiko-bot
2026-07-30 9:05 ` Jiebin Sun [this message]
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=20260730090521.2206375-10-jiebin.sun@intel.com \
--to=jiebin.sun@intel.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=dapeng1.mi@linux.intel.com \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=thomas.falcon@intel.com \
--cc=tianyou.li@intel.com \
--cc=wangyang.guo@intel.com \
/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