From: Leo Yan <leo.yan@linaro.org>
To: "André Przywara" <andre.przywara@arm.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
Wei Li <liwei391@huawei.com>, James Clark <james.clark@arm.com>,
Dave Martin <Dave.Martin@arm.com>,
linux-kernel@vger.kernel.org, Al Grant <Al.Grant@arm.com>
Subject: Re: [PATCH v2 10/14] perf arm-spe: Refactor event type handling
Date: Wed, 21 Oct 2020 18:13:02 +0800 [thread overview]
Message-ID: <20201021101302.GA3194@leoy-ThinkPad-X240s> (raw)
In-Reply-To: <1406e767-e85a-e859-bfa2-221678e08392@arm.com>
Hi Andre,
On Wed, Oct 21, 2020 at 10:20:24AM +0100, André Przywara wrote:
[...]
> >>> --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> >>> +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> >>> @@ -284,58 +284,58 @@ int arm_spe_pkt_desc(const struct arm_spe_pkt *packet, char *buf,
> >>> if (ret < 0)
> >>> return ret;
> >>>
> >>> - if (payload & 0x1) {
> >>> + if (payload & SPE_EVT_PKT_GEN_EXCEPTION) {
> >>
> >> Having the bitmask here directly is indeed not very nice and error
> >> prone. But I would rather see the above solution:
> >> if (payload & BIT(EV_EXCEPTION_GEN)) {
> >
> > Will do.
> >
> >>> ret = arm_spe_pkt_snprintf(&buf, &blen, " EXCEPTION-GEN");
> >>> if (ret < 0)
> >>> return ret;
> >>> }
> >>> - if (payload & 0x2) {
> >>> + if (payload & SPE_EVT_PKT_ARCH_RETIRED) {
> >>> ret = arm_spe_pkt_snprintf(&buf, &blen, " RETIRED");
> >>> if (ret < 0)
> >>> return ret;
> >>> }
> >>> - if (payload & 0x4) {
> >>> + if (payload & SPE_EVT_PKT_L1D_ACCESS) {
> >>> ret = arm_spe_pkt_snprintf(&buf, &blen, " L1D-ACCESS");
> >>> if (ret < 0)
> >>> return ret;
> >>> }
> >>> - if (payload & 0x8) {
> >>> + if (payload & SPE_EVT_PKT_L1D_REFILL) {
> >>> ret = arm_spe_pkt_snprintf(&buf, &blen, " L1D-REFILL");
> >>> if (ret < 0)
> >>> return ret;
> >>> }
> >>> - if (payload & 0x10) {
> >>> + if (payload & SPE_EVT_PKT_TLB_ACCESS) {
> >>> ret = arm_spe_pkt_snprintf(&buf, &blen, " TLB-ACCESS");
> >>> if (ret < 0)
> >>> return ret;
> >>> }
> >>> - if (payload & 0x20) {
> >>> + if (payload & SPE_EVT_PKT_TLB_WALK) {
> >>> ret = arm_spe_pkt_snprintf(&buf, &blen, " TLB-REFILL");
> >>> if (ret < 0)
> >>> return ret;
> >>> }
> >>> - if (payload & 0x40) {
> >>> + if (payload & SPE_EVT_PKT_NOT_TAKEN) {
> >>> ret = arm_spe_pkt_snprintf(&buf, &blen, " NOT-TAKEN");
> >>> if (ret < 0)
> >>> return ret;
> >>> }
> >>> - if (payload & 0x80) {
> >>> + if (payload & SPE_EVT_PKT_MISPREDICTED) {
> >>> ret = arm_spe_pkt_snprintf(&buf, &blen, " MISPRED");
> >>> if (ret < 0)
> >>> return ret;
> >>> }
> >>> if (idx > 1) {
> >>
> >> Do you know what the purpose of this comparison is? Surely payload would
> >> not contain more bits than would fit in "idx" bytes? So is this some
> >> attempt of an optimisation?
> >
> > Here "idx" is for payload size (in bytes); you could see function
> > arm_spe_get_events() calculate the payload size:
> >
> > packet->index = PAYLOAD_LEN(buf[0]);
> >
> > Please note, the raw payload size (field "sz" in header) value is:
> >
> > 0b00 Byte.
> > 0b01 Halfword.
> > 0b10 Word.
> > 0b11 Doubleword.
> >
> > After using PAYLOAD_LEN(), the payload size is converted to value in
> > byte, so:
> >
> > packet->index = 1 << "sz";
> >
> > 1 Byte
> > 2 Halfword
> > 4 Word
> > 8 Doubleword
> >
> > In Armv8 ARM, chapter "D10.2.6 Events packet", we can see the events
> > "Remote access", "Last Level cache miss" and "Last Level cache access"
> > are only valid when "sz" is equal or longer than Halfword, thus idx is
> > 2/4/8; this is why here checks the condition "if (idx > 1)".
>
> Right, thanks for the explanation. But in the end this is just a lot of
> words for: "You can only fit n*8 bits in n bytes.", isn't it?
> So if the payload size is 1 bytes, we can't have bits 8 or higher.
>
> And in arm_spe_get_payload() we load payload with casts, so the upper
> bits, beyond the payload size, must always be 0? Regardless of what was
> in the buffer. Or am I looking at the wrong function?
You are right! Sorry I didn't connect with the function
arm_spe_get_payload(), so packet->payload has been been casted, so we
don't need to do extra checking for payload size at here.
Will remove the condition checking in next spin.
Thanks a lot!
Leo
> Even if that wouldn't be the case, I'd rather mask it here again, so
> that we can rely on this, and lose the extra check.
>
> >
> >> If so, I doubt it's really useful, the
> >> compiler might find a smarter solution to the problem. Just continuing
> >> with the bit mask comparison would make it look nicer, I think.
> >
> > ARMv8 ARM gives out "Otherwise this bit reads-as-zero.", IIUC this
> > suggests to firstly check the size, if cannot meet the size requirement,
> > then the Event bit should be reads-as-zero.
>
> But as mentioned above, we take care of this already:
> switch (payload_len) {
> case 1: packet->payload = *(uint8_t *)buf; break;
> case 2: packet->payload = le16_to_cpu(*(uint16_t *)buf); break;
> ...
>
> Thanks,
> Andre
next prev parent reply other threads:[~2020-10-21 10:13 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-29 13:39 [PATCH v2 00/14] perf arm-spe: Refactor decoding & dumping flow Leo Yan
2020-09-29 13:39 ` [PATCH v2 01/14] perf arm-spe: Include bitops.h for BIT() macro Leo Yan
2020-10-08 13:44 ` André Przywara
2020-09-29 13:39 ` [PATCH v2 02/14] perf arm-spe: Fix a typo in comment Leo Yan
2020-10-08 13:44 ` André Przywara
2020-09-29 13:39 ` [PATCH v2 03/14] perf arm-spe: Refactor payload length calculation Leo Yan
2020-10-08 13:44 ` André Przywara
2020-10-12 0:21 ` Leo Yan
2020-09-29 13:39 ` [PATCH v2 04/14] perf arm-spe: Fix packet length handling Leo Yan
2020-10-08 13:45 ` André Przywara
2020-09-29 13:39 ` [PATCH v2 05/14] perf arm-spe: Refactor printing string to buffer Leo Yan
2020-10-08 13:46 ` André Przywara
2020-10-12 0:29 ` Leo Yan
2020-09-29 13:39 ` [PATCH v2 06/14] perf arm-spe: Refactor packet header parsing Leo Yan
2020-10-08 19:49 ` André Przywara
2020-10-12 1:00 ` Leo Yan
2020-09-29 13:39 ` [PATCH v2 07/14] perf arm-spe: Refactor address packet handling Leo Yan
2020-10-19 9:01 ` André Przywara
2020-10-19 10:41 ` Leo Yan
2020-09-29 13:39 ` [PATCH v2 08/14] perf arm-spe: Refactor context " Leo Yan
2020-10-20 21:53 ` André Przywara
2020-09-29 13:39 ` [PATCH v2 09/14] perf arm-spe: Refactor counter " Leo Yan
2020-10-20 21:53 ` André Przywara
2020-10-21 3:52 ` Leo Yan
2020-09-29 13:39 ` [PATCH v2 10/14] perf arm-spe: Refactor event type handling Leo Yan
2020-10-20 21:54 ` André Przywara
2020-10-21 4:54 ` Leo Yan
2020-10-21 9:20 ` André Przywara
2020-10-21 10:13 ` Leo Yan [this message]
2020-09-29 13:39 ` [PATCH v2 11/14] perf arm-spe: Refactor operation packet handling Leo Yan
2020-09-29 13:39 ` [PATCH v2 12/14] perf arm-spe: Add more sub classes for operation packet Leo Yan
2020-10-20 21:54 ` André Przywara
2020-10-21 5:16 ` Leo Yan
2020-09-29 13:39 ` [PATCH v2 13/14] perf arm_spe: Decode memory tagging properties Leo Yan
2020-09-29 13:39 ` [PATCH v2 14/14] perf arm-spe: Add support for ARMv8.3-SPE Leo Yan
2020-10-20 21:54 ` André Przywara
2020-10-21 5:10 ` Leo Yan
2020-10-21 9:26 ` André Przywara
2020-10-21 10:17 ` Leo Yan
2020-10-21 14:53 ` André Przywara
2020-10-22 0:44 ` Leo Yan
2020-10-13 14:53 ` [PATCH v2 00/14] perf arm-spe: Refactor decoding & dumping flow Arnaldo Carvalho de Melo
2020-10-13 15:19 ` Leo Yan
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=20201021101302.GA3194@leoy-ThinkPad-X240s \
--to=leo.yan@linaro.org \
--cc=Al.Grant@arm.com \
--cc=Dave.Martin@arm.com \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=andre.przywara@arm.com \
--cc=james.clark@arm.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=liwei391@huawei.com \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--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