From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BC8C3C4727C for ; Tue, 29 Sep 2020 14:06:04 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 19C8C20848 for ; Tue, 29 Sep 2020 14:06:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="TyvNBpPA" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 19C8C20848 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=uGtCklQJJUzzwv/u4guAiSSv9ZXzIezSEjDZ3JE/boc=; b=TyvNBpPA7d3B3EvKrprdZTgYM 7SnSdW2lL4QdN1/PYuOXm9nCXjDFE+oDJuaIJWfJ14qaG/pdewGXl02sV/XZMlVNulNrtxr6o77kz 4ifgcsFoTTpSi+whIo0GKgZqY/BxrycJoP8kY9zJg7JpVYsYV4Gk7y828+yQEicWVjWL9EP084mnZ mJV88q2JSoLQo7de4Jf3lc27AV8Xblix5Ivzb92iUnorbb36r6ztG9XOlisty12l3JMbv+TOmNhCH soJuK5O3avIH8y0PcwgS5DVkt7APKeR0wRVvX7AZ7lZ5y385J045vtUHoRdDxv2maIu7uaPJG8TT8 ltJB6jrLw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kNGEv-00045V-Df; Tue, 29 Sep 2020 14:04:21 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kNGEM-0003u2-4G for linux-arm-kernel@lists.infradead.org; Tue, 29 Sep 2020 14:03:50 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 099E012FC; Tue, 29 Sep 2020 07:03:42 -0700 (PDT) Received: from arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CD5943F6CF; Tue, 29 Sep 2020 07:03:39 -0700 (PDT) Date: Tue, 29 Sep 2020 15:03:37 +0100 From: Dave Martin To: Leo Yan Subject: Re: [PATCH 5/5] perf: arm_spe: Decode SVE events Message-ID: <20200929140334.GL6642@arm.com> References: <20200922101225.183554-1-andre.przywara@arm.com> <20200922101225.183554-6-andre.przywara@arm.com> <20200928132114.GF6642@arm.com> <8efd63eb-5ae7-0f9a-6c37-ef5e68af4e6c@arm.com> <20200928144755.GI6642@arm.com> <20200929021902.GA16749@leoy-ThinkPad-X240s> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200929021902.GA16749@leoy-ThinkPad-X240s> User-Agent: Mutt/1.5.23 (2014-03-12) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200929_100346_293959_4E47EA74 X-CRM114-Status: GOOD ( 26.76 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Al Grant , linux-arm-kernel@lists.infradead.org, Suzuki K Poulose , Peter Zijlstra , =?iso-8859-1?Q?Andr=E9?= Przywara , Jiri Olsa , linux-kernel@vger.kernel.org, Arnaldo Carvalho de Melo , Alexander Shishkin , Ingo Molnar , James Clark , Catalin Marinas , Namhyung Kim , Will Deacon , Tan Xiaojun , Wei Li Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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=E9 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 exten= sion > > > >> 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 <=3D n <=3D 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel