[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210629060924.GD163942@leoy-ThinkPad-X240s>
Date: Tue, 29 Jun 2021 14:09:24 +0800
From: Leo Yan <leo.yan@...aro.org>
To: Mathieu Poirier <mathieu.poirier@...aro.org>
Cc: James Clark <james.clark@....com>, acme@...nel.org,
coresight@...ts.linaro.org, al.grant@....com,
branislav.rankov@....com, denik@...omium.org,
suzuki.poulose@....com, anshuman.khandual@....com,
John Garry <john.garry@...wei.com>,
Will Deacon <will@...nel.org>,
Mike Leach <mike.leach@...aro.org>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...hat.com>,
Namhyung Kim <namhyung@...nel.org>,
linux-arm-kernel@...ts.infradead.org,
linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7 2/2] perf cs-etm: Split --dump-raw-trace by AUX records
Hi Mathieu,
On Mon, Jun 28, 2021 at 02:01:32PM -0600, Mathieu Poirier wrote:
[...]
> > > Hi Leo,
> > >
> > > I think this is not true in piped mode because there is no auxtrace index.
> > > In that mode, events are processed only in file order and cs_etm__process_auxtrace_event()
> > > is called for each buffer.
> > >
> > > You can reproduce this with something like this:
> > >
> > > ./perf record -o - ls > stdio.data
> > > cat stdio.data | ./perf report -i -
> >
> > You are right! I tried these two commands with cs_etm event, just as
> > you said, in this case, the AUX trace data is not queued; so the flow
> > for "if (!etm->data_queued)" should be kept. If so, I am very fine
> > for current change. Thanks for sharing the knowledge.
> >
> > > There are some other Coresight features that don't work as expected in this mode, like
> > > sorting timestamps between CPUs. The aux split patchset won't work either because random
> > > access isn't possible. And the TRBE patch that I'm working on now won't work, because it
> > > also requires the random access to lookup the flags on the AUX record to configure the
> > > decoder for unformatted trace.
> >
>
> There is a lot of things happening in this area. Based on the above should I
> still plan to review this set or should I wait for another revision?
I think you could continue to review this patch set for AUX data splitting.
Since we have concern for the AUX data splitting with snapshot mode,
James and me both have verified the AUX data splitting (this patch
set) with snapshot mode, and the testing result shows this patch set
is reliable.
Regard another patch set for fixing snapshot mode [1], I will send a new
version (drop patch 1/3 and refine for patch 3/3), so you could hold
on for that patch set.
Thanks,
Leo
[1] https://lore.kernel.org/patchwork/cover/1437696/
Powered by blists - more mailing lists