public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Martin <Dave.Martin@arm.com>
To: Leo Yan <leo.yan@linaro.org>
Cc: "Mark Rutland" <mark.rutland@arm.com>,
	"Al Grant" <Al.Grant@arm.com>, "Will Deacon" <will@kernel.org>,
	"Suzuki K Poulose" <suzuki.poulose@arm.com>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"André Przywara" <andre.przywara@arm.com>,
	"Jiri Olsa" <jolsa@redhat.com>,
	linux-kernel@vger.kernel.org,
	"Arnaldo Carvalho de Melo" <acme@kernel.org>,
	"Alexander Shishkin" <alexander.shishkin@linux.intel.com>,
	"Ingo Molnar" <mingo@redhat.com>,
	"James Clark" <james.clark@arm.com>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Namhyung Kim" <namhyung@kernel.org>,
	"Wei Li" <liwei391@huawei.com>,
	"Tan Xiaojun" <tanxiaojun@huawei.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 5/5] perf: arm_spe: Decode SVE events
Date: Tue, 29 Sep 2020 15:03:37 +0100	[thread overview]
Message-ID: <20200929140334.GL6642@arm.com> (raw)
In-Reply-To: <20200929021902.GA16749@leoy-ThinkPad-X240s>

On Tue, Sep 29, 2020 at 10:19:02AM +0800, Leo Yan wrote:
> On Mon, Sep 28, 2020 at 03:47:56PM +0100, Dave Martin wrote:
> > On Mon, Sep 28, 2020 at 02:59:34PM +0100, André Przywara wrote:
> > > On 28/09/2020 14:21, Dave Martin wrote:
> > > 
> > > Hi Dave,
> > > 
> > > > On Tue, Sep 22, 2020 at 11:12:25AM +0100, Andre Przywara wrote:
> > > >> The Scalable Vector Extension (SVE) is an ARMv8 architecture extension
> > > >> that introduces very long vector operations (up to 2048 bits).
> > > > 
> > > > (8192, in fact, though don't expect to see that on real hardware any
> > > > time soon...  qemu and the Arm fast model can do it, though.)

[...]

> > Mostly I'm curious because the encoding doesn't match the SVE
> > architecture: SVE requires 4 bits to specify the vector length, not 3.
> > This might have been a deliberate limitation in the SPE spec., but it
> > raises questions about what should happen when 3 bits is not enough.
> > 
> > For SVE, valid vector lengths are 16 bytes * n
> > or equivalently 128 bits * n), where 1 <= n <= 16.
> > 
> > The code here though cannot print EVLEN16 or EVLEN48 etc.  This might
> > not be a bug, but I'd like to understand where it comes from...
> 
> In the SPE's spec, the defined values for EVL are:
> 
>   0b'000 -> EVLEN: 32 bits.
>   0b'001 -> EVLEN: 64 bits.
>   0b'010 -> EVLEN: 128 bits.
>   0b'011 -> EVLEN: 256 bits.
>   0b'100 -> EVLEN: 512 bits.
>   0b'101 -> EVLEN: 1024 bits.
>   0b'110 -> EVLEN: 2048 bits.
> 
> Note that 0b'111 is reserved.  In theory, I think SPE Operation packet
> can support up to 4196 bits (32 << 7) when the EVL field is 0b'111; but

OK, having looked at the spec I can now confirm that this look correct.
I was expecting a more direct correspondence between the SVE ISA and
these events, but it looks like SPE may report on a finer granularity
than whole instructions, hence showing effective vector lengths smaller
than 32; also SPE rounds the reported effective vector length up to a
power of two, which allows the full range of lengths to be reported via
the 3-bit EVL field.

> it's impossible to express vector length for 8192 bits as you mentioned.

Yes, ignore my comment about 8192-bit vectors: I was confusing myself
(the Linux API extensions support up to 8192 _bytes_ per vector in order
to have some expansion room just in case; however the SVE architecture
limits vectors to at most 2048 bits).

So I don't see any obvious issues.

It might be a good idea to explicitly reject the encoding 0b111, since
we can't be certain what it is going to mean -- however, I don't have a
strong opinion on this.

Cheers
---Dave

  reply	other threads:[~2020-09-29 14:03 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-22 10:12 [PATCH 0/5] perf: arm64: Support ARMv8.3-SPE extensions Andre Przywara
2020-09-22 10:12 ` [PATCH 1/5] arm64: spe: Allow new bits in SPE filter register Andre Przywara
2020-09-27  2:51   ` Leo Yan
2020-09-22 10:12 ` [PATCH 2/5] perf: arm_spe: Add new event packet bits Andre Przywara
2020-09-27  3:03   ` Leo Yan
2020-09-22 10:12 ` [PATCH 3/5] perf: arm_spe: Add nested virt event decoding Andre Przywara
2020-09-27  3:11   ` Leo Yan
2020-09-22 10:12 ` [PATCH 4/5] perf: arm_spe: Decode memory tagging properties Andre Przywara
2020-09-27  3:19   ` Leo Yan
     [not found]     ` <20201013145103.GE1063281@kernel.org>
2020-10-13 14:52       ` Arnaldo Carvalho de Melo
2020-09-22 10:12 ` [PATCH 5/5] perf: arm_spe: Decode SVE events Andre Przywara
2020-09-27  3:30   ` Leo Yan
2020-09-28 10:15     ` André Przywara
2020-09-28 11:08       ` Leo Yan
2020-09-28 13:21   ` Dave Martin
2020-09-28 13:59     ` André Przywara
2020-09-28 14:47       ` Dave Martin
2020-09-29  2:19         ` Leo Yan
2020-09-29 14:03           ` Dave Martin [this message]
2020-09-30 10:34           ` Dave Martin
2020-09-30 11:04             ` Leo Yan
2020-10-05 10:15               ` Dave Martin

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=20200929140334.GL6642@arm.com \
    --to=dave.martin@arm.com \
    --cc=Al.Grant@arm.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=andre.przywara@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=james.clark@arm.com \
    --cc=jolsa@redhat.com \
    --cc=leo.yan@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --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 \
    --cc=suzuki.poulose@arm.com \
    --cc=tanxiaojun@huawei.com \
    --cc=will@kernel.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