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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 314CAE77198 for ; Mon, 6 Jan 2025 17:36:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BABE26B0089; Mon, 6 Jan 2025 12:36:15 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B5E066B008A; Mon, 6 Jan 2025 12:36:15 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A4B686B0092; Mon, 6 Jan 2025 12:36:15 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 8D0C96B0089 for ; Mon, 6 Jan 2025 12:36:15 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 12BFD1C60F4 for ; Mon, 6 Jan 2025 17:36:15 +0000 (UTC) X-FDA: 82977730710.27.5925E9A Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) by imf19.hostedemail.com (Postfix) with ESMTP id 6E6301A000E for ; Mon, 6 Jan 2025 17:36:13 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf19.hostedemail.com: domain of riel@shelob.surriel.com designates 96.67.55.147 as permitted sender) smtp.mailfrom=riel@shelob.surriel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736184973; a=rsa-sha256; cv=none; b=GWqxpHx6OeC1kQr9RF5kNR6AZmDgUOX6eBWR41KejFmE9JFw/5FXvKOOW6V18Lrp1SnNdU zwGqiqW7Alznoz6FLj4V1FQHffm7MGL1fikScIAs0lNZZMRetAYnC8b27Veh1pNk3YcGi5 tkk/Og0620A08IoGES5bF+7C1aVRidc= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf19.hostedemail.com: domain of riel@shelob.surriel.com designates 96.67.55.147 as permitted sender) smtp.mailfrom=riel@shelob.surriel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736184973; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8yXaj2wYLA4csbMqb9SQfSukYIehJmmglL1CSqvUCRI=; b=nJ50tb1rEjC3lCttgFM52w7YZbKrTOZDt0jm7t4WFezqMhq61H9j76TgSa0osFUSgRuVXl b2+4sK2H9Wqdo/s/bAmvUWsXyNAOXYIFhnKx/oCRWrw8nifk8W4kfQF2zkMOhcS+NFcCys MCK1DH+1z46Ub/ReAYQjwQASjl8TISg= Received: from fangorn.home.surriel.com ([10.0.13.7]) by shelob.surriel.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.97.1) (envelope-from ) id 1tUr0X-000000004Ds-0wdn; Mon, 06 Jan 2025 12:35:17 -0500 Message-ID: <978b4da7c7949e70a515fd04279e12a39e575f1b.camel@surriel.com> Subject: Re: [PATCH 07/12] x86/tlb: use INVLPGB in flush_tlb_all From: Rik van Riel To: Dave Hansen , x86@kernel.org Cc: linux-kernel@vger.kernel.org, kernel-team@meta.com, dave.hansen@linux.intel.com, luto@kernel.org, peterz@infradead.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, akpm@linux-foundation.org, nadav.amit@gmail.com, zhengqi.arch@bytedance.com, linux-mm@kvack.org Date: Mon, 06 Jan 2025 12:35:17 -0500 In-Reply-To: <194072ff-32af-4a5d-8e73-0a45f75290e7@intel.com> References: <20241230175550.4046587-1-riel@surriel.com> <20241230175550.4046587-8-riel@surriel.com> <194072ff-32af-4a5d-8e73-0a45f75290e7@intel.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.1 (3.54.1-1.fc41) MIME-Version: 1.0 X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 6E6301A000E X-Stat-Signature: hx6i5qh9b5uewrxxfumuyzkfkti5ug91 X-Rspam-User: X-HE-Tag: 1736184973-331062 X-HE-Meta: U2FsdGVkX1/oghcW+CoGldoH2vYGoW83rb9BK0qsrNGlxoDWpmVn8LfO3mqAgXrbdtZS8v3hmxStTDRaLtK+omf9gQEPjm+oPQW0ARktpqhqG4ageRci7tD0WYu1ioJGnrHBE1D9KncywFgE/o5Xp1hyJTWCC5SypnLDvKm3UQfPfy5TaKrstmtG33IJs6VVqJ0DRKs55yMa2DLefu4X6sbiNumNZEVXzGRQ9qelO4uyQSI42DilUy7Byj5REAnIlWpYK8RQbVELx3/Q6JBg2u54EsBAGJL8PiwjgW2M5PqJSnIJtjwary2symAbDssCuk0s7/RTQP3zHv0KmL/TCNWyWcYO72A0h7ywmaro08glZ9me6QlqwSeDc09Z8Ac5oULHx41p+tgDU4rVzkKAsQT6tO3M9RgRq+ZHXJKaZ8d2y1wnGlDqd4kNqaPsPOs32+/N0VmU4bMfws96mZRpLC4/ON2AxZVNnLnaGBrsdxbP/sN5idGRxmUjw0d0HVpJl1DrXa8B43/7PW95VgxK3sP3r2uvZGdDQXwinwxhOxHMzto4xzqZuhNBDgKRrSbh2IbRBn9FmK5c0b/4cXuGCh5bXfEEPjNEtWlfOGsmHU5VvmbFrvfOKVYjYdGca79Ektb9v4ZMza6OF7K+LMA2NvB3uDApOtG375VNvqTeCPW+7vDOp7jetX5iO/2AtNMdTC3jmLH/ZhYjLFynB6EtWMrvL3VQZTKqbuMMsEO5lunCvQ9rXmdwqbtsBfaiXRo8rG92fMHVMEvtTw7Wt3sTCEHvus9TxV+87Qk7m/QICXg23viqGi1ovcI3S+O03NMbv9Zx4WYlDdlQ2wTBOPCwsLfY2F1yk07cftFbEk59Q3GQjhnctkAD6gItWqhUsjzG1dDCx065GS47TwoYISb50O7TlN39pqEfP9vfSb4S4ZfZAqqzL17d6EL4AGS0OJVc6oAfHHCqLE7b+3dj22z ZVFG7J+D mqFGSxPS8bOJOQItvSkXXvCZzZSg8JmRKIms/iG8rD0Q8Tk1OusrYq0dhilu39dfZJMInknWV8AMZnSL7rWWWt86NkLYG5Ez7Ka0j/GpoTIvNu18OWuL55Ca/r3ntylElEeRRUpFOJj0cVcoDs4YiJ39oGr1+4K/gyO+j682nUrBRCeX0I5V2YYrb3w2U+qoHWOzVr2I/r9Xbej/leKWDL9qHYtPolQSvcdTI99ZkWynlRY8174cLMrZypv0QKTp+BEV+ZDoVngnQpDi13ryE8BDl8u1AkGqGy9OFG75fX1y4dHxz+KI0NJZhMeLRJ/nWB37SfvtIa0Ce1B9TSTIITyudgk7yh1ng6sybLQROpLML9BhLo+Lbjn8XvpR11Baf+UPh X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon, 2025-01-06 at 09:29 -0800, Dave Hansen wrote: > On 12/30/24 09:53, Rik van Riel wrote: > > --- a/arch/x86/mm/tlb.c > > +++ b/arch/x86/mm/tlb.c > > @@ -1074,6 +1074,12 @@ static void do_flush_tlb_all(void *info) > > =C2=A0void flush_tlb_all(void) > > =C2=A0{ > > =C2=A0 count_vm_tlb_event(NR_TLB_REMOTE_FLUSH); > > + if (cpu_feature_enabled(X86_FEATURE_INVLPGB)) { > > + guard(preempt)(); > > + invlpgb_flush_all(); > > + tlbsync(); > > + return; > > + } >=20 > After seeing a few of these, I'd really prefer that the preempt and > tlbsync() logic be hidden in the invlpgb_*() helper, or *a* helper at > least. >=20 > This would be a lot easier on the eyes if it were something like: >=20 > flushed =3D invlpgb_flush_all(); > if (flushed) > return; One issue here is that some of the invlpgb helpers are supposed to be asynchronous, because we can have multiple of those flushes pending simultaneously, and then wait for them to complete with a tlbsync. How would we avoid the confusion between the two types (async vs sync) invlpgb helpers? I'm all for cleaning this up, but I have not thought of a good idea yet... --=20 All Rights Reversed.