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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 562A8CD8CBD for ; Thu, 5 Sep 2024 17:52:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=21J5CLF95TnNYdCBIdk1gEbv43cMrwtOpbo4BisCRGo=; b=JN5VAr9ZN7RIemXPPCI5vBLNHb jf91RIRucC7jbu7ZmBPNL1VY+KczcKromBJFt7hwXQov/ZAAIrpPeN9Q4yMFppNSqo6gPbBWnG9+N z20wHxl48rjPeyiOUYc+f/b/Q+rQw6w9aDYGo7TuGnn78J8AOfQM9GWVZmbojxjQWb6quw5HDtVgS JYFfUazc8fEVIHQ7kXP18uD4vBzq5yEUEH7WgKz0ZmjiozXqSIcEt2bue79TxaiRLglvIvs11eAgw acbNHcQqG7SEMa78yszibibT85CtILKnSxkoX0qI+ZhISYBf5g9CFlF0HJkvsjQrHd9jx/SezymZL J93lRC0A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1smGep-00000009Lis-3ola; Thu, 05 Sep 2024 17:52:36 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1smGdq-00000009LSZ-3HLy for linux-arm-kernel@lists.infradead.org; Thu, 05 Sep 2024 17:51:36 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 7C2505C53DF; Thu, 5 Sep 2024 17:51:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8285CC4CEC3; Thu, 5 Sep 2024 17:51:32 +0000 (UTC) Date: Thu, 5 Sep 2024 18:51:30 +0100 From: Catalin Marinas To: Mark Brown Cc: Will Deacon , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Mark Rutland Subject: Re: [PATCH] arm64/fpsimd: Ensure we don't contend a SMCU from idling CPUs Message-ID: References: <20240618-arm64-sme-no-cpuidle-v1-1-1de872e1691f@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240905_105134_909452_EFDB5BB6 X-CRM114-Status: GOOD ( 24.32 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org (replying to the previous version as it looks like I haven't followed up on the discussion) On Thu, Jul 11, 2024 at 12:28:12AM +0100, Mark Brown wrote: > On Wed, Jul 10, 2024 at 09:10:53PM +0100, Catalin Marinas wrote: > > On Tue, Jun 18, 2024 at 02:57:42PM +0100, Mark Brown wrote: > > > + /* > > > + * Leaving SME enabled may leave this core contending with > > > + * other cores if we have a SMCU, disable whenever we enter > > > + * idle to avoid this. Only do this if they're actually > > > + * enabled to avoid overhead in cases where we don't enter a > > > + * low enough power state to loose register state. > > > + */ > > > + if (system_supports_sme() && > > > + (read_sysreg_s(SYS_SVCR) & (SVCR_SM_MASK | SVCR_ZA_MASK))) > > > + fpsimd_save_and_flush_cpu_state(); > > > +} > > > Do we always enter here via the idle thread? If we already had a thread > > switch we probably don't need to save the SME state again, only flush > > the state. > > If we've actually switched the thread then TIF_FOREIGN_FPSTATE has been > set and we'll just check the flag and return for the save portion rather > than actually writing any register values out so the overhead should be > minimal. It feels safer to check in case we get better at doing the > save lazily. OK, so likely the state is already saved, all we need to do here is flush the state and SMSTOP. But why would switching to idle be any different than switching to a thread that doesn't used SME? It feels like we are just trying to optimise a special case only. Could we not instead issue an SMSTOP in the context switch code? Also this looks hypothetical until we have some hardware to test it on, see how it would behave with a shared SME unit. -- Catalin