From: Ali Saidi <alisaidi@amazon•com>
To: <german.gomez@arm•com>
Cc: <acme@kernel•org>, <alexander.shishkin@linux•intel.com>,
<alisaidi@amazon•com>, <andrew.kilroy@arm•com>,
<benh@kernel•crashing.org>, <james.clark@arm•com>,
<john.garry@huawei•com>, <jolsa@redhat•com>, <leo.yan@linaro•org>,
<linux-arm-kernel@lists•infradead.org>,
<linux-kernel@vger•kernel.org>,
<linux-perf-users@vger•kernel.org>, <mark.rutland@arm•com>,
<mathieu.poirier@linaro•org>, <mingo@redhat•com>,
<namhyung@kernel•org>, <peterz@infradead•org>, <will@kernel•org>
Subject: Re: [PATCH 1/2] perf arm-spe: Add arm_spe_record to synthesized
Date: Thu, 27 Jan 2022 19:13:45 +0000 [thread overview]
Message-ID: <20220127191345.18173-1-alisaidi@amazon.com> (raw)
In-Reply-To: <c4a96839-1b4b-ac4d-38aa-26c1f4c8645a@arm.com>
On 26/01/2022 19:07, German Gomez wrote:
[...]
>>> Have you tried this with perf-inject? I think it would need the PERF_SAMPLE_RAW bit in the sample_type,
>> Yes I've tried the following and it worked as expected with the original
>> perf.data or the perf.data.jitted after perf-inject.
>>
>> perf record -e arm_spe_0/jitter=1/ -k 1 java ...
>> perf inject -f --jit -i perf.data -o perf.data.jitted
>
>This is not injecting the synthesized samples. I think it is still
>processing from the aux trace. Try adding "--itrace=i1i --strip" to the
>inject command to remove the AUXTRACE events. Judging by the raw
>samples, the data is missing:
>
> [...]
Yep, you're correct here. If I use the command above the raw samples are lost.
>>> Although I quickly looked over the perf inject code and it looks like it's expecting some type of padding:
>>>
>>> [...]
>>>
>>> I'm seeing some comments in utils/event.h related to this on the intel events.
>> Yes i noticed this too,but looking at how the raw data is added to the same
>> other places like intel-pt.c:1703 the perf_synth__raw*() functions are used to
>> strip away the 4 bytes bytes before the data is added to the sample. The other
>> places i can find the padding used is in builtin-script.c but given we have the
>> --dump-raw-trace option it's not clear to me that it's needed to wrap the
>> arm_spe_event in another struct with padding like perf_synth_intel_ptwrite?
>
>I think the intel use case makes sense because the layout of the data
>is fixed and documented. If we modify the struct arm_spe_record later it
>may not be obvious how to match it to the raw data of an older perf.data
>file. And we're generating bigger files with redundant information.
Not injecting the samples into the perf trace, but having a way to support
custom scripts parsing the data would be really useful and much faster than
trying to parse back the --dump-raw-trace output into something useful. The
other way to go would be to put a header that describes the version of the spe
struct at the head of it to address any future changes, but I'm not familiar
with a workflow that would benefit from the added complexity.
Thanks,
Ali
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists•infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-01-27 19:15 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-25 19:20 [PATCH 0/2] Allow perf scripts to process SPE raw data Ali Saidi
2022-01-25 19:20 ` [PATCH 1/2] perf arm-spe: Add arm_spe_record to synthesized sample Ali Saidi
2022-01-25 20:47 ` German Gomez
2022-01-26 15:58 ` [PATCH 1/2] perf arm-spe: Add arm_spe_record to synthesized Ali Saidi
2022-01-26 19:07 ` German Gomez
2022-01-27 19:13 ` Ali Saidi [this message]
2022-01-25 19:20 ` [PATCH 2/2] perf arm-spe: Parse more SPE fields and store source Ali Saidi
2022-01-28 17:20 ` German Gomez
2022-01-28 21:02 ` Ali Saidi
2022-02-11 16:31 ` German Gomez
2022-02-12 4:19 ` Leo Yan
2022-02-21 20:41 ` German Gomez
2022-02-22 19:29 ` Ali Saidi
2022-02-25 12:40 ` German Gomez
2022-02-27 13:54 ` Leo Yan
2022-02-27 13:20 ` Leo Yan
2022-03-01 10:54 ` German Gomez
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=20220127191345.18173-1-alisaidi@amazon.com \
--to=alisaidi@amazon$(echo .)com \
--cc=acme@kernel$(echo .)org \
--cc=alexander.shishkin@linux$(echo .)intel.com \
--cc=andrew.kilroy@arm$(echo .)com \
--cc=benh@kernel$(echo .)crashing.org \
--cc=german.gomez@arm$(echo .)com \
--cc=james.clark@arm$(echo .)com \
--cc=john.garry@huawei$(echo .)com \
--cc=jolsa@redhat$(echo .)com \
--cc=leo.yan@linaro$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-perf-users@vger$(echo .)kernel.org \
--cc=mark.rutland@arm$(echo .)com \
--cc=mathieu.poirier@linaro$(echo .)org \
--cc=mingo@redhat$(echo .)com \
--cc=namhyung@kernel$(echo .)org \
--cc=peterz@infradead$(echo .)org \
--cc=will@kernel$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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