All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Namhyung Kim <namhyung@kernel.org>
Cc: Ingo Molnar <mingo@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	James Clark <james.clark@linaro.org>,
	Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Clark Williams <williams@redhat.com>,
	linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
	Arnaldo Carvalho de Melo <acme@kernel.org>
Subject: [PATCH v3 0/4] perf tools: Add progress diagnostics and a false-sharing workload
Date: Tue, 29 Sep 2026 00:06:30 +0200	[thread overview]
Message-ID: <20260928220634.2451784-1-acme@kernel.org> (raw)

Hi,

This series adds progress and stuck-process diagnostics to perf, and a
workload that makes false sharing visible to data type profiling.

The changes are:

  - move perf_config__set_variable() to util/config.c and serialize config
    parser and read-modify-write state, so non-builtin perf code can persist
    configuration changes safely;

  - add 'perf report --progress' for stdio users, showing the current phase,
    percentage, and counts while a session is processed;

  - add the prototype tools/perf/scripts/perf-stuck.sh helper, which samples
    a running perf process and can invoke the accompanying GDB commands when
    progress stops;

  - add 'perf test -w false_sharing', a synthetic TCP-shaped workload with
    identity and packet counters sharing a cacheline, and include it in the
    data type profiling shell test.

The progress backend handles nested phases and completes them on error paths
as well as successful paths. The false-sharing workload uses a shared
volatile instance so the data type profiler can resolve direct accesses to
the individual members.

The perf-stuck helper is intentionally a prototype and requires the usual
/proc access; its optional GDB mode additionally requires gdb and suitable
debug information. When only one CPU is available, the false-sharing
workload warns that it cannot produce cross-CPU traffic but still runs.

Testing:

  make -C tools/perf -j4
  tools/perf/perf test -w false_sharing
  taskset -c 0 tools/perf/perf test -w false_sharing
  bash -n tools/perf/scripts/perf-stuck.sh
  bash -n tools/perf/tests/shell/data_type_profiling.sh
  git diff --check 0ae6fc78c5ce0dfd..485532296710225862daf8ffb19802ae327efe2a

Best regards,

- Arnaldo

What changed from v2:

  - tools/perf/util/config.c: perf_etc_perfconfig() returned NULL when the
    allocation in system_path() fails, and none of its callers check for
    that.  Reported by Sashiko while reviewing v2: the deref reached from
    this series was fixed, and since the same unchecked deref is already
    reachable from the three callers predating it, perf_config_from_file()
    and 'perf daemon' among them, the opportunity was taken to make the
    accessor total as well, falling back to the unresolved path, which for
    the usual absolute ETC_PERFCONFIG is the same string;

  - tools/perf/scripts/perf-stuck.gdb: don't dereference map_symbol.sym
    without checking it for NULL, printing "(no symbol)" instead.  Reported
    by Sashiko while reviewing v2;

  - tools/perf/scripts/perf-stuck.gdb: note next to the structure walks
    that a REFCNT_CHECKING build wraps some structs in a proxy holding the
    original, where this has to read map->orig->dso->orig->name;

  - tools/perf/scripts/perf-stuck.sh: count the samples showing no progress
    when there is no progress to look at, as an empty or missing progress
    log reset the counter on every sample and never fired -g;

  - tools/perf/scripts/perf-stuck.sh: use `--` for pgrep and tail, as a
    process name starting with a hyphen was taken as an option and had the
    script attach to an unrelated process, gdb included when -g is used;

  - tools/perf/scripts/perf-stuck.sh: bound the gdb run with
    `timeout --signal=INT 30`, as the script makes inferior calls and one
    into a perf wedged in a loop never returns, while SIGINT lets gdb
    release the inferior instead of leaving perf stopped.

What changed from v1:

  - avoid calling CPU_SET() with -1 when false_sharing runs with only one
    CPU available in its affinity mask.

   tools/perf/Documentation/perf-report.txt      |  13 +
  tools/perf/builtin-config.c                   |  70 +----
  tools/perf/builtin-report.c                   |  10 +
  tools/perf/scripts/perf-stuck.gdb             | 109 ++++++++
  tools/perf/scripts/perf-stuck.sh              | 184 ++++++++++++++
  tools/perf/tests/builtin-test.c               |   1 +
  tools/perf/tests/shell/data_type_profiling.sh |   9 +-
  tools/perf/tests/tests.h                      |   1 +
  tools/perf/tests/workloads/Build              |   2 +
  tools/perf/tests/workloads/false_sharing.c    | 240 ++++++++++++++++++
  tools/perf/ui/Build                           |   1 +
  tools/perf/ui/progress.h                      |   2 +
  tools/perf/ui/stdio/progress.c                | 162 ++++++++++++
  tools/perf/util/config.c                      | 131 +++++++++-
  tools/perf/util/config.h                      |   2 +
  tools/perf/util/ordered-events.c              |  16 +-
  tools/perf/util/session.c                     |  12 +-
  17 files changed, 882 insertions(+), 83 deletions(-)
  create mode 100644 tools/perf/scripts/perf-stuck.gdb
  create mode 100755 tools/perf/scripts/perf-stuck.sh
  create mode 100644 tools/perf/tests/workloads/false_sharing.c
  create mode 100644 tools/perf/ui/stdio/progress.c

base-commit: 0ae6fc78c5ce0dfd
v1-head: 45d7917f7e05e8a29828ed5f0bbdc94fc938f79f
v2-head: d4f84e4de8890194924ccd897a8e6773e7d4240b
--
Assisted-by: OpenCode: GPT-5.6 Luna

             reply	other threads:[~2026-09-28 22:06 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-28 22:06 Arnaldo Carvalho de Melo [this message]
2026-09-28 22:06 ` [PATCH 1/4] perf config: Move perf_config__set_variable() to util/config.c Arnaldo Carvalho de Melo
2026-09-28 22:19   ` sashiko-bot
2026-09-28 22:06 ` [PATCH 2/4] perf report: Add --progress option Arnaldo Carvalho de Melo
2026-09-28 22:12   ` sashiko-bot
2026-09-29 18:29   ` Namhyung Kim
2026-09-28 22:06 ` [PATCH 3/4] perf scripts: Add perf-stuck, to tell where a running perf is stuck Arnaldo Carvalho de Melo
2026-09-28 22:16   ` sashiko-bot
2026-09-29 18:31   ` Namhyung Kim
2026-09-28 22:06 ` [PATCH 4/4] perf test: Add false_sharing workload exhibiting cross-CPU false sharing Arnaldo Carvalho de Melo
2026-09-28 22:14   ` sashiko-bot

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=20260928220634.2451784-1-acme@kernel.org \
    --to=acme@kernel.org \
    --cc=adrian.hunter@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=mingo@kernel.org \
    --cc=namhyung@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=williams@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.