Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\))
Subject: Re: Problem running perf using Intel-PT with snapshots
From:   Nadav Amit <nadav.amit@gmail.com>
In-Reply-To: <a8127cb3-7693-22e9-7ace-547f7eb4403b@intel.com>
Date:   Thu, 18 May 2023 10:56:02 -0700
Cc:     LKML <linux-kernel@vger.kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Namhyung Kim <namhyung@kernel.org>,
        linux-perf-users@vger.kernel.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <CBE205D4-C798-419D-A9B2-42870245B885@gmail.com>
References: <6325A777-706E-462A-8931-59E16D4E37A5@gmail.com>
 <a8127cb3-7693-22e9-7ace-547f7eb4403b@intel.com>
To:     Adrian Hunter <adrian.hunter@intel.com>
Precedence: bulk


> On May 18, 2023, at 12:52 AM, Adrian Hunter <adrian.hunter@intel.com> =
wrote:
>=20
> On 18/05/23 07:26, Nadav Amit wrote:
>> Hello perf masters,
>>=20
>> I am running perf with Intel PT with snapshot mode and the result =
makes no
>> sense. I tried to figure it out myself but failed.
>>=20
>> Excluding the first data file, the rest seem messed up in various =
ways. The
>> only thing that repeatedly shows are calls to __fentry__+0x0. I would =
note
>> that ftrace is not enabled, and I turned off mitigations as I thought =
it
>> might somehow be related, but it did not help.
>>=20
>> Here is an example for execution and output. In between I ran
>> `kill -SIGUSR2 [perf-pid]`. To dump some traces.
>>=20
>> Any ideas what it might be?
>>=20
>> Thanks,
>> Nadav
>>=20
>> --
>>=20
>> $ perf record -e intel_pt/noretcomp=3D1/k --kcore --timestamp -a =
--snapshot=3De262144 --switch-output -m,64
>=20
> --switch-output does not work well with Intel PT.  Intel PT needs all =
of the sideband event information from all files, so decoding errors =
result from splitting files.
>=20
> If you need separate files, consider stopping and restarting 'perf =
record' instead.  If you do that, you may want to look at options like =
-B and -N and --no-bpf-event which can affect how long it takes to stop =
perf record.
>=20
> If you don't need separate files, you can use --time to look at time =
ranges within the resulting perf.data file.

Thank you Adrian. It was driving me crazy and I was sure I am somehow =
not
accounting for some ftrace/rethunk or some other binary rewriting event.

These ideas for workarounds should suffice.

Thanks again,
Nadav=