All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Richter <tmricht@linux.ibm.com>
To: Ian Rogers <irogers@google.com>, Jens Remus <jremus@linux.ibm.com>
Cc: Jan Polensky <japo@linux.ibm.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Heiko Carstens <hca@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	Ilya Leoshkevich <iii@linux.ibm.com>,
	linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
	linux-s390@vger.kernel.org
Subject: Re: [PATCH] perf evsel: Improve callchain warning for s390
Date: Thu, 24 Sep 2026 11:40:11 +0200	[thread overview]
Message-ID: <a79daeb6-394c-434a-8896-a1bd48337f8d@linux.ibm.com> (raw)
In-Reply-To: <CAP-5=fUM6gb9MY9Sm=QhC+Tc4AFt2=fdLbr4tES++AMQcxryUQ@mail.gmail.com>

On 9/23/26 18:37, Ian Rogers wrote:
> On Tue, Sep 22, 2026 at 7:43 AM Jens Remus <jremus@linux.ibm.com> wrote:
>>
>> On s390 the kernel uses s390 back chain instead of frame pointers for
>> stack tracing of user space since v6.7 commit aa44433ac4ee ("s390: add
>> USER_STACKTRACE support").  This is because frame pointers on s390
>> cannot be used for stack tracing. [1]
>>
>> This requires user space to maintain a s390 back chain.  For instance
>> user space to be built with compiler option '-mbackchain' (instead of
>> '-fno-omit-frame-pointer' used on other architectures, which should
>> better not be used on s390 [1]).  Only few distributions and users build
>> user space with '-mbackchain'.  Therefore '--call-graph fp' may in
>> practice not produce the expected results.
>>
>> Commit ca76fb67ebdd ("perf evlist: Improve default event for s390")
>> changed the default '-g' option to 'dwarf' on s390 and added a warning
>> for s390 that wrongly claimed that "Framepointer unwinding lacks kernel
>> support".  This warning resulted from a misinterpretation of comments
>> in s390 cpumsf_pmu_event_init().
>>
>> The restriction in cpumsf_pmu_event_init() applies to callchain sampling
>> with the s390 CPU Measurement Sampling Facility (CPUMSF) hardware PMU.
>> CPUMSF events, such as 'cycles', do not support callchain sampling.
>> This is independent of whether perf uses the 'fp' or 'dwarf' call-graph
>> mode.  The CPUMSF PMU provides samples collected asynchronously, making
>> it impossible to associate a callchain to the historic IPs.  Therefore
>> callchains can only be used with software events on s390.
>>
>> Remove the incorrect warning.  The kernel supports the 'fp' call-graph
>> mode on s390 by walking the back chain.  Do not replace it with a
>> hint to use 'dwarf' when the resulting callchain is incomplete.  Such a
>> suggestion could imply that 'fp' is inherently inferior.  The same
>> general limitation exists on other architectures when user space is not
>> built with frame pointers (i.e. '-fno-omit-frame-pointers').
>>
>> Instead, warn on s390 when callchain sampling is requested with an event
>> provided by the CPUMCF or CPUMSF hardware PMUs, because that combination
>> is not supported.
>>
>> Update the perf record documentation to state that 'dwarf' is the
>> default call-graph mode on s390 and that 'fp' uses back chain instead
>> of frame pointers on s390.
>>
>> Note that '--call-graph fp' may also be useful for other applications,
>> such as OpenJDK maintaining a s390 back chain (does not require JVM
>> option '-XX:+PreserveFramePointer' on s390):
>>
>>   $ perf record --call-graph fp ... -- \
>>     java -XX:+UnlockDiagnosticVMOptions -XX:+DumpPerfMapAtExit ...
>>
>> [1]: s390: Stack tracing using Frame Pointer, Back Chain, and SFrame,
>>      https://conf.gnu-tools-cauldron.org/opo25/talk/Y3CVHY/
>>
>> Fixes: ca76fb67ebdd ("perf evlist: Improve default event for s390")
>> Signed-off-by: Jens Remus <jremus@linux.ibm.com>
> 
> Acked-by: Ian Rogers <irogers@google.com>
> 
> Thanks,
> Ian
> 
>> ---
>>
>> Notes (jremus):
>>     Changes in v3:
>>     - Updated warning message.
>>     - Rebased on v7.3-rc4.
>>
>>  tools/perf/Documentation/perf-record.txt | 7 ++++++-
>>  tools/perf/util/evsel.c                  | 6 +++---
>>  2 files changed, 9 insertions(+), 4 deletions(-)
>>
>> diff --git a/tools/perf/Documentation/perf-record.txt b/tools/perf/Documentation/perf-record.txt
>> index 178f483140ed..dc72606cb25d 100644
>> --- a/tools/perf/Documentation/perf-record.txt
>> +++ b/tools/perf/Documentation/perf-record.txt
>> @@ -293,7 +293,7 @@ OPTIONS
>>
>>  --call-graph::
>>         Setup and enable call-graph (stack chain/backtrace) recording,
>> -       implies -g.  Default is "fp" (for user space).
>> +       implies -g.  Default is "fp" for user space (s390 uses "dwarf").
>>
>>         The unwinding method used for kernel space is dependent on the
>>         unwinder used by the active kernel configuration, i.e
>> @@ -329,6 +329,11 @@ OPTIONS
>>         enable deferred user callchain which will collect user-space callchains
>>         when the thread returns to the user space.
>>
>> +       On s390, the "fp" method uses back chain instead of frame pointers,
>> +       which requires user space to maintain a back chain (e.g. compiler
>> +       option -mbackchain).  Without a maintained back chain this produces
>> +       bogus call graphs.  In that case use "dwarf" instead.
>> +
>>  -q::
>>  --quiet::
>>         Don't print any warnings or messages, useful for scripting.
>> diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
>> index d4cb455f4a7d..55297b8dab37 100644
>> --- a/tools/perf/util/evsel.c
>> +++ b/tools/perf/util/evsel.c
>> @@ -1092,9 +1092,9 @@ static void __evsel__config_callchain(struct evsel *evsel, const struct record_o
>>         bool function = evsel__is_function_event(evsel);
>>         struct perf_event_attr *attr = &evsel->core.attr;
>>
>> -       if (EM_HOST == EM_S390 && param->record_mode == CALLCHAIN_FP) {
>> -               pr_warning_once(
>> -                       "Framepointer unwinding lacks kernel support. Use '--call-graph dwarf'\n");
>> +       if (EM_HOST == EM_S390 && evsel->pmu && !perf_pmu__is_software(evsel->pmu)) {
>> +               pr_warning_once("Cannot use hardware PMU 'cpum_cf' / 'cpum_sf' event with callchain. "
>> +                               "Use a software 'cpu-clock' / 'task-clock' event.\n");
>>         }
>>
>>         evsel__set_sample_bit(evsel, CALLCHAIN);
>>
>> base-commit: 93f51579e7df248780214094418f205253383cc5
>> --
>> 2.53.0
>>

Reviewed-by: Thomas Richter <tmricht@linux.ibm.com>

-- 
Thomas Richter, Dept 3303, IBM s390 Linux Development, Boeblingen, Germany
--
IBM Deutschland Research & Development GmbH

Vorsitzender des Aufsichtsrats: Wolfgang Wendt

Geschäftsführung: David Faller

Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294

  reply	other threads:[~2026-09-24  9:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-22 14:43 [PATCH] perf evsel: Improve callchain warning for s390 Jens Remus
2026-09-22 14:47 ` sashiko-bot
2026-09-23 16:37 ` Ian Rogers
2026-09-24  9:40   ` Thomas Richter [this message]
2026-09-24 17:41     ` Arnaldo Carvalho de Melo

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=a79daeb6-394c-434a-8896-a1bd48337f8d@linux.ibm.com \
    --to=tmricht@linux.ibm.com \
    --cc=acme@kernel.org \
    --cc=agordeev@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=iii@linux.ibm.com \
    --cc=irogers@google.com \
    --cc=japo@linux.ibm.com \
    --cc=jremus@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=namhyung@kernel.org \
    /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.