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 537EEE77188 for ; Fri, 10 Jan 2025 16:11:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D54E06B00C8; Fri, 10 Jan 2025 11:11:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D046A6B00C9; Fri, 10 Jan 2025 11:11:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BF2E16B00CA; Fri, 10 Jan 2025 11:11:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 647FA6B00C8 for ; Fri, 10 Jan 2025 11:11:36 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 291D9AFED5 for ; Fri, 10 Jan 2025 16:11:36 +0000 (UTC) X-FDA: 82992032592.23.C67801F Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) by imf02.hostedemail.com (Postfix) with ESMTP id 89F738000A for ; Fri, 10 Jan 2025 16:11:33 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf02.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=1736525493; a=rsa-sha256; cv=none; b=2uxvyu1f+9h5TL7iIukqfgyNXjc7COq76dPQKuumCPrghF4CR/QT5glhq7m4V+GVUitVoF Ex2vOxhZJL2HwDcZK/j44V4lIZXx2x5WZ0pi/jYH435Gm4sVThGQKHoml0YgnugCWZpUDt sxeGg+MNXBeLdh03bA0v9TJ6AaqSoe4= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf02.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=1736525493; 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=j+FkcpM6Zqd6WwrwE6unByXsxOxFo52laL0TvKkNGkQ=; b=W2I8OKuFlwvagSd0YI1xoNXg4h+y1T4pT/PmX+RSJKsbQMKrYMkdssWxF2DQXk1ePZHwsT AixTJqi0sVGYp1UiC0VVYAt7e7lzkixUUYYNxKJ1JFJJJ8CtIn58MWDvcBFD5a4t5vsFiN 2GPD9/3LobTm/gYaJ+yyPu8YzBcwooQ= 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 1tWHYI-000000003fm-3lhh; Fri, 10 Jan 2025 11:08:02 -0500 Message-ID: Subject: Re: [PATCH 06/12] x86/mm: use INVLPGB for kernel TLB flushes From: Rik van Riel To: Dave Hansen , 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: Fri, 10 Jan 2025 11:08:02 -0500 In-Reply-To: <915c9c4e-75a7-4c4e-90a5-9a3de93bec1d@intel.com> References: <20241230175550.4046587-1-riel@surriel.com> <20241230175550.4046587-7-riel@surriel.com> <855298e6e981378c3afeab93b8c3cb821a7a5b88.camel@surriel.com> <426011a9-1fbc-415c-bac7-df5d67417df3@intel.com> <915c9c4e-75a7-4c4e-90a5-9a3de93bec1d@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-Stat-Signature: q4c93fgdunre5k17tjpyok98y91isqoc X-Rspam-User: X-Rspamd-Queue-Id: 89F738000A X-Rspamd-Server: rspam08 X-HE-Tag: 1736525493-922391 X-HE-Meta: U2FsdGVkX1/mnZyhZcTYBQVtXo96El/Za1utab4V7ZCv2Yss1lr+aJsLgG2l1esrSWNhWZX3T6j5oNH2GP9A9ivE7/MoZPSAHPIRjJleEaCAS/qMdZgC2rvpnja3slDTIIjiTGVuI9KdVxyOh4Ik4vocEyjk4I2I3JohuXdDoMdpLLTSOwCmqrLaTeCL8U2csuu+3rAjeZyvso/HzGUz4gUojMMvqha4qz98A0Vbj9Jo1mBDNkecDxdgrcmgioS4gxjGmMSZF3sZh5b9WuwsAcX2FdY6sUScMWgOyC95s7/U5KNah6hVL12O9p+sSRt5en60nj5AjjUZ6A7o+JDMTr5CHXMK+by9HtXckeZ1mbEgNAy2mO+o5bKIZs467eNL+qd1b48OywkqjQItcdimj4HpvEGX/ZpULSQh/lplKPkoNt2ElVzcgmwLQYcow4smFR0wIMK/Vby6GrJrqUTMv65zM8pIW8j35E4lvHgPsp7ABMiQYiLuzTs3oqtJF1jYWwcl068t81Nmu8sysJX/Kz44gswWIe/ApvG13w2IJj7a8rOmnCkgdUnj4V9w2HRd4+SmCh9Yi3FS/cbFtMb68qOmUas3smCD/yfpSgmmJCwDiF4j++e1km4P7SFewCtuNg18JS/X4FvHQ3nd3rcrlNkkQRS2ekxPBx6S64iuYYPClGNLOogWx7/vaTjNFe29P7zrzrhzlO3h2h2TjjnxoCU4fUPUnDMf/rlVqNq8mFFgC61n8hjuNwKUSnMrYSLi0DA41y7oC8LiJqWJjQr20K73k5GE1DhGC9TmoUit/lnzAtYiH3rk16soqmD9lpb61mw8E0J2+zxrfl86OAXCAyqOmaKSCJtbPUpgduhi3x5BoeLrCPf6f76IiOGj6B94ivstZEwcrmSTVMMNvJ5bhbumzltfiGlHjHqZHeB7O4SVmvkA+nNsQHIpSCpBr5MNbxNQA+/+NGko0gV/qpy 5+YYzUxO i4gCHTeD35HjTxpS242379ePZB2jMyjHfNw8+DB9DT3Ky70Zv+g6pVGGIklGcqTCm8RezVLQhGg8kxY69rtNwmwCUcTb5ot+Achk/EyD/FqhHukr2uOvRhQdu6mUKL2XsEzmt+5HM8ZlzoKvLbGDlbITN2wP3qHtxNCCuxx+ntylc1lGdGLQEf8BiaTHSUPIeXSsZOyThBB0JrDXP9ALjYknxZl07rL9lp2oKypNs/qRczKdGKJcIIaHUwlwM8ks82oYIj0nBVq7l8HiyMt1SpzYujyP1APUEiZJkSKavmfccBjl8YZE4OWpLf8UgJjpzDonKTHFnh+F2euMS25APGzUNVg== 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 Fri, 2025-01-10 at 07:14 -0800, Dave Hansen wrote: > On 1/9/25 22:07, Nadav Amit wrote: > > This is not my reading. I think that this reading assumes that > > besides > > the broadcast, some new =E2=80=9Crange flush=E2=80=9D was added to the = TLB. My > > guess > > is that this not the case, since presumably it would require a > > different > > TLB structure (and who does 2 changes at once =F0=9F=98=89 ). >=20 > Reading it again, I think you're right. >=20 > The INVLPG and INVLPGB language is too close. It would also _talk_ > about > invalidating a range rather than just incrementing an address to > invalidate. >=20 > I think the key thing we need to decide is whether to treat a single > INVLPGB(stride=3D8) more like a single INVLPGB or eight INVLPGBs. > Measuring a bunch of invalidation looks should tell us that. Would I be wrong to assume that the CPUs have some optimizations built in to efficiently execute an invalidation for "everything in a PCID"? The "global invalidate" we send does not zap everything in the TLB, but only the translations for a single PCID. I suppose we should measure these things at some point (after I do the other cleanups?), because the CPUs may well have made a bunch of optimizations that we don't know about. --=20 All Rights Reversed.