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 ED502E7718B for ; Wed, 1 Jan 2025 16:24:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 62D6A6B0082; Wed, 1 Jan 2025 11:24:15 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5DB816B0083; Wed, 1 Jan 2025 11:24:15 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4CB146B0085; Wed, 1 Jan 2025 11:24:15 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 2DE4D6B0082 for ; Wed, 1 Jan 2025 11:24:15 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id A40671C7E58 for ; Wed, 1 Jan 2025 16:24:14 +0000 (UTC) X-FDA: 82959403590.21.435305B Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) by imf13.hostedemail.com (Postfix) with ESMTP id 9E50620009 for ; Wed, 1 Jan 2025 16:23:25 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf13.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=1735748630; 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=/syA+GqHaTCmcCjy0k9geA5OWfVDg8Cf7ydH3S7V+kA=; b=lGU1hmTFh89NMXKYw9RydVMCyTSjtFtArq291VFsy+BBSydQn0L+FpHeST4F5fitEtViyD ANzzIdfPLuA/Eb2PdLvK3M3LQqR0Ln5uVhR493z4uXnVqkNK23QUFX7hldeiOUneXpn4Hh GSjBCi08QfGiSUl2XV4GbOm58wolxUU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1735748630; a=rsa-sha256; cv=none; b=wQ2lm/VsL0H8RI3Y0cos5dR+z6Mp0c7YNyKd9RIrpFZLFlOjkML0ZenFWgIBh07t8brT0K ZDfp3KGV9ugvPTePuUCQFLfvDSBIg+0nWlMtO5tzNsQdlZbPmvGMl/CUjOHLEjRKsXSvpE Bo8CwLRcOzVLVdNlckqzqKx/AtOtcc8= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf13.hostedemail.com: domain of riel@shelob.surriel.com designates 96.67.55.147 as permitted sender) smtp.mailfrom=riel@shelob.surriel.com 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 1tT1V0-000000006W3-16kJ; Wed, 01 Jan 2025 11:23:10 -0500 Message-ID: <7be55c4eb33aac4f9b99c70bfd4578934fbdd0ea.camel@surriel.com> Subject: Re: [PATCH 09/12] x86/mm: enable broadcast TLB invalidation for multi-threaded processes From: Rik van Riel To: Karim Manaouil , Nadav Amit Cc: the arch/x86 maintainers , Linux Kernel Mailing List , kernel-team@meta.com, Dave Hansen , luto@kernel.org, peterz@infradead.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Andrew Morton , zhengqi.arch@bytedance.com, "open list:MEMORY MANAGEMENT" Date: Wed, 01 Jan 2025 11:23:09 -0500 In-Reply-To: <20250101161556.lniuomixy75vmj5g@ed.ac.uk> References: <20241230175550.4046587-1-riel@surriel.com> <20241230175550.4046587-10-riel@surriel.com> <95b614577f5475a919c878d6906d721004c83584.camel@surriel.com> <24c9b4b6-e07b-4cee-aa7f-6f317a1b7ef6@gmail.com> <20250101161556.lniuomixy75vmj5g@ed.ac.uk> 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-Stat-Signature: wwxmyf64jur9qstbruxo9e1dsb6b7rb7 X-Rspamd-Queue-Id: 9E50620009 X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1735748605-302195 X-HE-Meta: U2FsdGVkX1+JizucnjyjpVENEr0OAO2RP20YlzkqgUGgT1NN4tLCsZaTeW2wPy2vzCxprMTYJNy9G/yqy1J55N2t33mVD8kUVp9heh4isB7c0tqewIjWT82AkDCdH58EYY6A58beP3qvHoN/vAlbtn+AeQBMm8au4cHSJIgshLeuP2oUGquNgLNNxsacYKJ6WZpjz2UuYoAMoIMvl/wMc09calUgFlaYtW4QQepXoys2BB6SpizWQU8FPHrQCGk5/MHu612w7QfIZjzjNFFVZWjPqohiTQzrN1npOvRcNDpK6sETI2KJmcsBZEPm3EBc+/xGLkelFzDoI8MFt+ssGt2Oz386GkoTHq0Y0f9m18luq5GfmE9aEgnCWE+5dtWQz506kjPiix+QOXyLlGaFtLSDswwJQXvvMPw4LlCpmr/rw7/g7KAr68irhTqXJw2jJBPz2Dcuz24JNJNqJa3fpepOC7FLDUkcnlHBNo5/uYWXcBAjurQGTcY7jVlXNs69uVU3czDdJ/bS6h1zth0yAyuYBtaMsyzPI8RoRmYDZ0aybZPV67huTcW8W6e/+T6686Q9GsbfoMML+LByTa4KzLQEGFQKgDqnA/GyTqOs8ZCV4dEzUnOgHZDTm6mS5R7g0GD0RfxvORRQyiRM32i1YS7vTtWgRWHQIedD4oc5zbG5TkATreEuAxsNSZiZzqmwLSrTQNQ4VDm3uGn74r5J0gs3tQ3wFY6zMnUn1Oq1CJN0nc++wtuJHueFGq4fJDth7RV8470WeJjhCBK7pBFbAzC7u0938UNSENw7avzC1/R3togDKzKz7KGcDLi3z2GBcijEbOv4FY8wlqvQ+SL1XW93Bu1APiDnNWwunITMrjovXJYQa4snDPkQYT6IBQWeXMkchhz1B5n8M6XWeo9X7oYLmdjVns6si4GEFTHFESnBlbKUZj+wupEhWAKujwiZGHgRyc8Q+v5OlNwWuhB mhMz9qqa fJinqnxQ+wSRMqOYtaWOaq+vWJHYSTvv/pOZ8AuKSUBS/GMTlO4Z5UAVSgLgsqkve1GxtORl7jknA9gx/TbJrYVRuq4rOWTSXQtcXYjNzHXPeQrIrgcLkiWrcYHqKMhNGkna8Zv5U9uA2X8tSxJ4nSt5UOaNQVcx+yxTMhjohL1HiFCfFJpplYGLj//+GgC8G7MjzqiDubzQmHfvXn0d0xCsuRIrbBp0SgIP0yxCkreeF9+reUy6sMmJn+mD2li4MjBXuxiq4l4p23E32DL2yPgyAVOK19CP9uP59ZCU1nEJp8W7+qEGN7ZCnUlPsyAYKgoGelkOivQ6svFXQeNM2qUO6Lw== 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 Wed, 2025-01-01 at 16:15 +0000, Karim Manaouil wrote: > On Wed, Jan 01, 2025 at 05:20:01PM +0200, Nadav Amit wrote: > >=20 > >=20 > > On 01/01/2025 6:42, Rik van Riel wrote: > > > Fixed for the next version. > >=20 > > Thanks Rik, > >=20 > > Admittedly, I don't feel great about my overall last review - it > > mostly > > focused on style and common BKMs. > >=20 > > I still don't quite get the entire logic. To name one thing that I > > don't > > understand: why do we need broadcast_asid_list and the complicated > > games of > > syncing it with broadcast_asid_used. Why wouldn't > > broadcast_asid_used > > suffice? >=20 > If I uderstand correctly from Rik's patch, I think the list is needed > to > save the flush for only when we run out of the ASID space (wrap > around). > Without the list, whenever the ASID bit is cleared, you also have to > flush > the TLBs. That's exactly it. The list will only contain processes that are active on multiple CPUs, and hit a TLB flush "at the right moment" to be assigned a broadcast ASID, which will be true for essentially every process that does a lot of TLB flushes and is long lived. However, something like a kernel build has lots of short lived, single threaded processes, for which we should not be using broadcast TLB flushing, and which will not need to remove themselves from the list at exit time. --=20 All Rights Reversed.