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.7 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,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 B5B3BC12002 for ; Wed, 21 Jul 2021 15:14:50 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 7E86761221 for ; Wed, 21 Jul 2021 15:14:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7E86761221 Authentication-Results: mail.kernel.org; dmarc=fail (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=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc: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=OcUTPXEPAjhKtQ7rNZFz5lHz7UOUsODNxdXxHyevLuo=; b=r10wdYuS+EjzHR mkfICW6+fMWAh7UC0BVtHJfG7qG2Sa5mp2qlapUMd6vptSTxNIIx3XTCsKo3CpDQn7AHQvoX4Yd9d L7E0ebU0sQVlk6EVhZFlEauiLS0J8+vYCFPI5TfoD2iNL6ipF4fuTwosmxqY6CccNhk2ohrg0hoGL N2v8XydH9rqUeyH5PppLCYV2xw9JhtIaEwGT/1yQObPFKmMtgdbsHhxzN0gVy8pYSMh/FS0+AQgSY t0MbWrVofiLLbxc15GX6AehG/1lZ9eV+MRXBob/Qpo+n1va5ZcVyr2phGT9nWhuUr8O7CdzvihqIB IqiqoxrzGCJbOOs6PZ1A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m6Du6-00GDqj-FM; Wed, 21 Jul 2021 15:12:59 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m6DJe-00G0Sp-K1 for linux-arm-kernel@lists.infradead.org; Wed, 21 Jul 2021 14:35:20 +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 E892A1042; Wed, 21 Jul 2021 07:35:12 -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 C6FE93F73D; Wed, 21 Jul 2021 07:35:11 -0700 (PDT) Date: Wed, 21 Jul 2021 15:33:54 +0100 From: Dave Martin To: Mark Brown Cc: Catalin Marinas , Will Deacon , Julien Grall , Zhang Lei , Daniel Kiss , Julien Grall , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v7 0/3] arm64/sve: Improve performance when handling SVE access traps Message-ID: <20210721143350.GX4187@arm.com> References: <20210303201117.24777-1-broonie@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210303201117.24777-1-broonie@kernel.org> 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-20210721_073518_763763_23CC9C8D X-CRM114-Status: GOOD ( 34.26 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Mar 03, 2021 at 08:11:14PM +0000, Mark Brown wrote: > This patch series aims to improve the performance of handling SVE access > traps, earlier versions were originally written by Julien Gral but based > on discussions on previous versions the patches have been substantially > reworked to use a different approach. The patches are now different > enough that I set myself as the author, hopefully that's OK for Julien. > > Per the syscall ABI, SVE registers will be unknown after a syscall. In > practice, the kernel will disable SVE and the registers will be zeroed > (except the first 128 bits of each vector) on the next SVE instruction. > Currently we do this by saving the FPSIMD state to memory, converting to > the matching SVE state and then reloading the registers on return to > userspace. This requires a lot of memory accesses that we shouldn't > need, improve this by reworking the SVE state tracking so we track if we > should trap on executing SVE instructions separately to if we need to > save the full register state. This allows us to avoid tracking the full > SVE state until we need to return to userspace and to convert directly > in registers in the common case where the FPSIMD state is still in > registers then, reducing overhead in these cases. > > As with current mainline we disable SVE on every syscall. This may not > be ideal for applications that mix SVE and syscall usage, strategies > such as SH's fpu_counter may perform better but we need to assess the > performance on a wider range of systems than are currently available > before implementing anything, this rework will make that easier. > > It is also possible to optimize the case when the SVE vector length > is 128-bit (ie the same size as the FPSIMD vectors). This could be > explored in the future, it becomes a lot easier to do with this > implementation. > > I need to confirm if this still needs an update in KVM to handle > TIF_SVE_FPSIMD_REGS properly, I'll do that as part of redoing KVM > testing but that'll take a little while and felt it was important to get > this out for review now. Just picking this up: While I think this was a worthwhile experiment, my concern here is that while the approach taken in this series is reasonable, it doesn't seem to reduce the amount of code or result in a net simplification. From my side I think it's probably best to stick with what we have, until someone comes up with something that's clearly easier to understand. So, I'd still favour the version based on Julien's code, which is more of an incremental change to what we already had (and I think was most of the way there in your post recent version of it). Sorry for sending you down a rabbit-hole! If the maintainers decide they prefer a new approach at some point though, I'm not going to argue with that. Cheers ---Dave [...] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel