[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <00079cfd-9524-9427-9817-4f1c2eacf89f@linux.intel.com>
Date: Fri, 2 Jul 2021 01:46:19 +0300
From: "Bayduraev, Alexey V" <alexey.v.bayduraev@...ux.intel.com>
To: Arnaldo Carvalho de Melo <acme@...nel.org>
Cc: Jiri Olsa <jolsa@...hat.com>, Namhyung Kim <namhyung@...nel.org>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
Andi Kleen <ak@...ux.intel.com>,
Adrian Hunter <adrian.hunter@...el.com>,
Alexander Antonov <alexander.antonov@...ux.intel.com>,
Alexei Budankov <abudankov@...wei.com>,
Riccardo Mancini <rickyman7@...il.com>
Subject: Re: [PATCH v8 12/22] perf report: Output data file name in raw trace
dump
On 30.06.2021 21:36, Arnaldo Carvalho de Melo wrote:
> Em Wed, Jun 30, 2021 at 06:54:51PM +0300, Alexey Bayduraev escreveu:
<SNIP>
>> @@ -2116,9 +2127,9 @@ static int __perf_session__process_decomp_events(struct perf_session *session)
>> break;
>>
>> size = event->header.size;
>> -
>> - if (size < sizeof(struct perf_event_header) ||
>> - (skip = perf_session__process_event(session, event, file_pos)) < 0) {
>
>
> The call to perf_session__process_event() will not be made if
>
> (size < sizeof(struct perf_event_header)
>
> evaluates to true, with your change it is being made unconditionally,
> also before it was using that file_pos variable, set to zero and
> possibly modified by the logic in this function.
>
> And I read just "perf report: Output data file name in raw trace", so
> when I saw this separate change to pass 'decomp->file_pos' and remove
> that 'file_pos = 0' part I scratched my head, then I read again the
> commit log messsage and there it says it also does this separate change.
>
> Please make it separate patch where you explain why this has to be done
> this way and what previous cset this fixes, so that the
> stable@...nel.org guys pick it as it sounds like a fix.
As I understand it, file_pos is mostly used to show file offset
in dump_event(), like:
_0x17cf08_ [0x28]: event: 9
In current implementation file_pos is always 0 for _uncompressed_ events:
0 [0x28]: event: 9
Also file_pos is used to do lseek() for some user events:
PERF_RECORD_HEADER_TRACING_DATA, PERF_RECORD_AUXTRACE. etc.
As long as the compressed event container does not contain user events,
everything is fine. Currently only CPU events are compressed.
We can only fix zero offset for uncompressed events in dump_event(),
unfortunately we cannot show the original file offset because we
uncompress the entire compressed container and do not know compressed
size of each event in the container.
Thus we have 3 options:
1. Show for each uncompressed event decomp->file_pos: offset to
compressed container event:
We will see a series of CPU events with the same file offset.
This is done by this patch.
2. Show decomp->file_pos + offset in uncompressed buffer.
We will see a series of CPU events with overlapping file offsets.
Better is to show something like file_pos:uncompressed_pos,
but this would require changing all calls to dump_event().
3. Keep 0
What in your opinion is more preferable?
>
>> + skip = perf_session__process_event(session, event, decomp->file_pos,
>> + decomp->file_path);
>> + if (size < sizeof(struct perf_event_header) || skip < 0) {
>> pr_err("%#" PRIx64 " [%#x]: failed to process type: %d\n",
>> decomp->file_pos + decomp->head, event->header.size, event->header.type);
>> return -EINVAL;
Also checking of
(size < sizeof(struct perf_event_header))
after perf_session__process_event() is incorrect.
Thanks,
Alexey
>> @@ -2149,10 +2160,12 @@ struct reader;
<SNIP>
Powered by blists - more mailing lists