From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2C5C51C3BE7 for ; Fri, 10 Jan 2025 16:36:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=96.67.55.147 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736527012; cv=none; b=rkKX+zeu3q99s00KWlw3qqxcty+gNlLLYhIXfSYF0LO4VPRzflnnq+8D0CN4XoGaE2FEWlHSfcF822ii8xlaR6TmoUh1MePrMo6V3Lvtyec9G9hi8CEhpVlISiDoIvlTC3AUMoMZNQswoGAmVL2V7WUlo0NiXtdeqJea+xqSMww= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736527012; c=relaxed/simple; bh=Qyk53/gmKHkwmPo2eTH9UWBeB0nZfwSufX8mhN1yTuc=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=JLdga1zjwdkIRjFWHFDkJ/+uGyFvokyv17kgXJcLstbuGM/rhFZW2gDBuCHjF1itM71r2TQEEsw8EHihHdf7L68X0nfnACdjHI5DjFY83RrX3+M7+QpP5ii87CIaRqoXjUKbEqvM3nnrlS06VATvxTEBFf1gCodwKxAIELHRKj4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=surriel.com; spf=pass smtp.mailfrom=shelob.surriel.com; arc=none smtp.client-ip=96.67.55.147 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=surriel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=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 1tWHzp-0000000042J-1JcC; Fri, 10 Jan 2025 11:36:29 -0500 Message-ID: <65c9fa727810df986c4e576799af430c35b9d40e.camel@surriel.com> 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:36:29 -0500 In-Reply-To: <5f099cc0-b5e0-4d15-95dd-7f4e9f3df5eb@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> <5f099cc0-b5e0-4d15-95dd-7f4e9f3df5eb@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) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Sender: riel@surriel.com On Fri, 2025-01-10 at 08:29 -0800, Dave Hansen wrote: > > about. >=20 > IIRC, the "big" invalidation modes are pretty cheap to execute. Most > of > the cost comes from the TLB refill, not the flush itself. >=20 > But there's no substitute for actually measuring it. There's some > wonky > stuff out there. The last time Andy L. went and looked at it, there > were > oddities like INVPCID's "Individual-address invalidation" and INVLPG > having surprisingly different performance. >=20 Agreed on all points. If you guys don't mind, I'm going to keep this on the back burner, while I work my way through all the suggested code cleanups and improvements first. --=20 All Rights Reversed.