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 0C8DFC12002 for ; Wed, 21 Jul 2021 16:40:58 +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 B94816113C for ; Wed, 21 Jul 2021 16:40:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B94816113C 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=DIQgxManOi6go6Bl5X0IK5bwacjBvmjNDZNb9oUGwVM=; b=U6PhPK/rO/Pki+ fZ34YUMlOJ/qjShW0k9Xm2KIrJ2UFqL2SLDDxlfuR5+y2Qj8t7hske2GnLVWy6N3SDXcAbMk/CpN6 v5xlxI0EtV+ydnTb2a+JlP3PJHEeN5/chrmwy58S1ozRoEeim/i8+VylqPdja4AwUlFzOtm4VMsf6 KrTD/zaCF1kdQxdeTiiGc3uHzHAaNxeMbu7tpsFCVDQCvb6g8hGUsaWjkYprBJFfiOE49zehTvPfX TpkF0iQ3w8NtUsPtiKaOY7+IR3Yufbu0IUus29hH2F8wrm6ZizgLn3Ws7wnv4p+zl6EO4kV46GSCT Pdzx0SJTFXo8+W7I6i6Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m6FFx-00GcBK-0c; Wed, 21 Jul 2021 16:39:37 +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 1m6FFt-00GcAV-LF for linux-arm-kernel@lists.infradead.org; Wed, 21 Jul 2021 16:39:35 +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 C1FC41FB; Wed, 21 Jul 2021 09:39:30 -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 A51F83F73D; Wed, 21 Jul 2021 09:39:29 -0700 (PDT) Date: Wed, 21 Jul 2021 17:38:12 +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: <20210721163811.GY4187@arm.com> References: <20210303201117.24777-1-broonie@kernel.org> <20210721143350.GX4187@arm.com> <20210721163429.GF4259@sirena.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210721163429.GF4259@sirena.org.uk> 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_093933_788791_E2BBAD8F X-CRM114-Status: GOOD ( 21.80 ) 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, Jul 21, 2021 at 05:34:29PM +0100, Mark Brown wrote: > On Wed, Jul 21, 2021 at 03:33:54PM +0100, Dave Martin wrote: > > > 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. > > I did find it was making it easier to understand some of what was going > on TBH - I forget which specific bits but I found the whole model of > specifying the goal state at a higher level clarified things for me. > It's definitely not saving much in the way of code though and the code > that was already merged to do the zeroing in place gives us most of the > win with dramatically less code, it just doesn't help if we do context > switch. > > > 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). > > I prefer Julien's approach too, the requirement to trigger the slow path > on return to userspace doesn't really work with the newer approach > AFAICT. If this gets resurrected I'll go back to the last _NO_FLUSH > version. OK, sounds fair -- thanks for the patience. Cheers ---Dave _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel