From: James Clark <james.clark@arm.com>
To: Namhyung Kim <namhyung@kernel.org>,
Denis Nikitin <denik@chromium.org>,
Stephane Eranian <eranian@google.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Jiri Olsa <jolsa@kernel.org>, Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
Ian Rogers <irogers@google.com>,
linux-perf-users@vger.kernel.org, Leo Yan <leo.yan@linaro.org>
Subject: Re: [PATCH 0/4] perf intel-pt: Fix the pipe mode (v1)
Date: Mon, 30 Jan 2023 10:56:49 +0000 [thread overview]
Message-ID: <43ff6d3d-2047-1b2f-12ab-849a915a6e2f@arm.com> (raw)
In-Reply-To: <CAM9d7chU6kTdG0y65_UaD_hW75GezzNJF1ZwjNWq8BUpACAGTA@mail.gmail.com>
On 27/01/2023 23:08, Namhyung Kim wrote:
> Hi James,
>
> On Fri, Jan 27, 2023 at 6:42 AM James Clark <james.clark@arm.com> wrote:
>>
>>
>>
>> On 27/01/2023 07:22, Adrian Hunter wrote:
>>> On 27/01/23 02:19, Namhyung Kim wrote:
>>>> Hello,
>>>>
>>>> I found some problems in Intel-PT and auxtrace in general with pipe.
>>>> In the past it used to work with pipe, but recent code fails.
>>>
>>> Pipe mode is a problem for Intel PT and possibly other auxtrace users.
>>
>> Just some info from my side: For Arm Coresight we ended up deprecating
>> pipe mode, then not supporting it altogether. First was when we added an
>> optional step to peek through all of the data to help with an edge case.
>> Then we added a requirement to receive a HW_ID packet before decoding
>> which necessitated the peek. You can't peek in pipe mode because you
>> need to be able to seek, so it's not supported at all anymore.
>>
>> For Arm SPE I never tested it with piped data. I suppose I could add a
>> test at some point, but I don't really see the usecase.
>
> Yeah, it'd be great if we can have a test for Arm SPE.
>
Ok thanks I will put it on the list of things to do.
> Anyway, my work env (Google) requires the pipe mode due to the
> restriction in disk usage. Without the pipe support, it's not possible
> to run `perf record` in production.
>
Makes sense. Unfortunately at the moment with Coresight, because of the
lack of appropriate timestamps we're waiting for the end of the file
before starting decoding. So you're not really any better off using
piped mode, unless you have a lot more memory than disk space?
Since this commit [1] and Arm v8.4 we can actually start making use of
the timestamps and do a streaming decode again. So I will also add it to
the list to look into that for Coresight again. Are you using an old
version of Perf or not using Coresight at all? I know Denis at Google is
using Coresight, but only with files rather than pipes.
One other thing, have you used the --switch-output mode to perf record
before? I would have said it would give you some of the benefits of
piped mode, but is more likely to work with Coresight. But last time I
checked it's not working either. Not very helpful I know, but something
to keep in mind.
James
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/commit/?h=perf/core&id=a7fe9a443b6064c68f86a2ee09bdfa7736660ef3
next prev parent reply other threads:[~2023-01-30 10:56 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-27 0:19 Namhyung Kim
2023-01-27 0:19 ` [PATCH 1/4] perf inject: Use perf_data__read() for auxtrace Namhyung Kim
2023-01-27 0:19 ` [PATCH 2/4] perf intel-pt: Do not try to queue auxtrace data on pipe Namhyung Kim
2023-01-27 0:19 ` [PATCH 3/4] perf session: Avoid calling lseek(2) for pipe Namhyung Kim
2023-01-27 15:34 ` James Clark
2023-01-27 0:19 ` [PATCH 4/4] perf test: Add pipe mode test to the Intel PT test suite Namhyung Kim
2023-01-27 7:22 ` [PATCH 0/4] perf intel-pt: Fix the pipe mode (v1) Adrian Hunter
2023-01-27 14:42 ` James Clark
2023-01-27 23:08 ` Namhyung Kim
2023-01-30 10:56 ` James Clark [this message]
2023-01-31 2:13 ` Namhyung Kim
2023-01-27 22:54 ` Namhyung Kim
2023-01-30 14:15 ` Arnaldo Carvalho de Melo
2023-01-30 17:35 ` Adrian Hunter
2023-01-31 2:19 ` Namhyung Kim
2023-01-27 15:32 ` James Clark
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=43ff6d3d-2047-1b2f-12ab-849a915a6e2f@arm.com \
--to=james.clark@arm.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=denik@chromium.org \
--cc=eranian@google.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=leo.yan@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--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
all inboxes | Powered by JetHome®