public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Namhyung Kim <namhyung@kernel.org>
To: James Clark <james.clark@linaro.org>
Cc: Ian Rogers <irogers@google.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Kan Liang <kan.liang@linux.intel.com>,
	linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org
Subject: Re: [PATCH v1] perf tests: Fix data symbol test with LTO builds
Date: Fri, 7 Mar 2025 10:02:09 -0800	[thread overview]
Message-ID: <Z8s0oQw3dxC11Ea2@google.com> (raw)
In-Reply-To: <ac1350fd-ef8d-485c-ab70-b38a3ffe9b87@linaro.org>

Hello,

On Thu, Feb 27, 2025 at 10:35:30AM +0000, James Clark wrote:
> 
> 
> On 27/02/2025 5:42 am, Ian Rogers wrote:
> > On Wed, Feb 26, 2025 at 3:01 PM Ian Rogers <irogers@google.com> wrote:
> > > 
> > > With LTO builds, although regular builds could also see this as
> > > all the code is in one file, the datasym workload can realize the
> > > buf1.reserved data is never accessed. The compiler moves the
> > > variable to bss and only keeps the data1 and data2 parts as
> > > separate variables. This causes the symbol check to fail in the
> > > test. Make the variable volatile to disable the more aggressive
> > > optimization. Rename the variable to make which buf1 in perf is
> > > being referred to.
> > > 
> > > Before:
> > > ```
> > > $ perf test -vv "data symbol"
> > > 126: Test data symbol:
> > > --- start ---
> > > test child forked, pid 299808
> > > perf does not have symbol 'buf1'
> > > perf is missing symbols - skipping test
> > > ---- end(-2) ----
> > > 126: Test data symbol                                                : Skip
> > > $ nm perf|grep buf1
> > > 0000000000a5fa40 b buf1.0
> > > 0000000000a5fa48 b buf1.1
> > > ```
> > > 
> > > After:
> > > ```
> > > $ nm perf|grep buf1
> > > 0000000000a53a00 d buf1
> > > $ perf test -vv "data symbol"126: Test data symbol:
> > > --- start ---
> > > test child forked, pid 302166
> > >   a53a00-a53a39 l buf1
> > > perf does have symbol 'buf1'
> > > Recording workload...
> > > Waiting for "perf record has started" message
> > > OK
> > > Cleaning up files...
> > > ---- end(0) ----
> > > 126: Test data symbol                                                : Ok
> > > ```
> > > 
> > > Fixes: 3dfc01fe9d12 ("perf test: Add 'datasym' test workload")
> > > Signed-off-by: Ian Rogers <irogers@google.com>
> > 
> > Ah, I see we're trying to force -O0 and -fno-inline in the Makefile
> > (git.kernel.org is giving 403s):
> > https://github.com/torvalds/linux/blob/master/tools/perf/tests/workloads/Build#L11
> > Which LTO later undoes. I'm not seeing LTO breakages for brstack.c and
> > the shell test "Check branch stack sampling". I think LTO is able to
> > optimize this case as it is a variable/struct being optimized, so the
> > "-O0" and "-fno-inline" mustn't be being made to apply. Not a wholly
> > satisfactory reason to add the volatile, but I'm short on
> > alternatives.
> > 
> > Thanks,
> > Ian
> > 
> > 
> > 
> 
> Adding -fno-lto to that file works for me (llvm-15):
> 
>   CFLAGS_datasym.o          = -fno-lto -g -O0 -fno-inline ...
> 
> In fact it looks like we should add this to everywhere we're already doing
> -g and -O0. If lto is just another form of optimisation it should be
> disabled as well.
 
Make sense.  But it turned out that disabling LTO caused some subtle
troubles in my work environment unfortunately. :(

Adding 'volatile' seems to be a simple and reasonable alternative and
I agree with the renaming.

Thanks,
Namhyung


  reply	other threads:[~2025-03-07 18:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-26 23:01 [PATCH v1] perf tests: Fix data symbol test with LTO builds Ian Rogers
2025-02-27  5:42 ` Ian Rogers
2025-02-27 10:35   ` James Clark
2025-03-07 18:02     ` Namhyung Kim [this message]
2025-03-08 18:24 ` Namhyung Kim

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=Z8s0oQw3dxC11Ea2@google.com \
    --to=namhyung@kernel.org \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=irogers@google.com \
    --cc=james.clark@linaro.org \
    --cc=jolsa@kernel.org \
    --cc=kan.liang@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox