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 E65541FE452 for ; Fri, 10 Jan 2025 05:31:44 +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=1736487116; cv=none; b=fhn41znsW4Y3bWGvLMN5lqFbqzQaNe9MiND+Sl+CB3XzyQt9ok9gs4OtoXEYsQ7fzV7uzt6MwZfYCBE1WoEPtd5zbbDS0CELl7ISF10h0g2Aec3u38g/2pkFGI8ElgMiCsU3MTuzFN8tPwj4f8m0lukKvETsGGVpYMIeUr6roUo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736487116; c=relaxed/simple; bh=cFnwn3tVSnBS9ABN6NOhxUyl2ygd/l5wbdqklFsw4CU=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=cYBXBwpoja5mNLdy+reLCpAG53W2Vl1nsDp++3+1uJDUfQzhexEO5ozXVqM5YWbN1MwqDUIFvDcUN0jfyW1RqgqQ2P4CHfULO6VCiymBScowDTJ20eB08IfMtOa30CcIbmS3Qnl4Spxj9gDDLaUIzSwlnN65/9XxYH1ffmgCYu4= 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 1tW7cC-000000004lC-09Hx; Fri, 10 Jan 2025 00:31:24 -0500 Message-ID: <1409344951af9427799bd28d7865c9ea7fa87ed3.camel@surriel.com> Subject: Re: [PATCH 06/12] x86/mm: use INVLPGB for kernel TLB flushes 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: Fri, 10 Jan 2025 00:31:23 -0500 In-Reply-To: <426011a9-1fbc-415c-bac7-df5d67417df3@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> 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 Thu, 2025-01-09 at 13:18 -0800, Dave Hansen wrote: >=20 > But actually I think INVLPGB is *WAY* better than INVLPG here.=C2=A0 > INVLPG > doesn't have ranged invalidation. It will only architecturally > invalidate multiple 4K entries when the hardware fractured them in > the > first place. I think we should probably take advantage of what > INVLPGB > can do instead of following the INVLPG approach. >=20 > INVLPGB will invalidate a range no matter where the underlying > entries > came from. Its "increment the virtual address at the 2M boundary" > mode > will invalidate entries of any size. That's my reading of the docs at > least. Is that everyone else's reading too? Ohhhh, good point! I glossed over that the first half dozen times I was reading the document, because I was trying to use the ASID, and working to figure out why things kept crashing (turns out I can only=20 use the PCID on bare metal) >=20 > So, let's pick a number "Z" which is >=3D invlpgb_count_max. Z could > arguably be set to tlb_single_page_flush_ceiling. Then do this: >=20 > =C2=A0=C2=A0 4k -> Z*4k =3D> use 4k step > >Z*4k -> Z*2M =3D> use 2M step > >Z*2M =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D> invalidate everything >=20 > Invalidations <=3DZ*4k are exact. They never zap extra TLB entries. >=20 > Invalidations that use the 2M step *might* unnecessarily zap some > extra > 4k mappings in the last 2M, but this is *WAY* better than > invalidating > everything. >=20 This is a great idea. Then the code in get_flush_tlb_info can adjust start, end, and stride_shift as needed. INVLPGB also supports invalidation of an entire 1GB region, so we can take your idea one step further :) With up to 8 pages zapped by a single INVLPGB instruction, and multiple in flight simultaneously, maybe we could set the threshold to 64, for 8 INVLPGBs in flight at once? That way we can invalidate up to 1/8th of a 512 entry range with individual zaps, before just zapping the higher level entry. > "Invalidate everything" obviously stinks, but it should only be for > pretty darn big invalidations.=20 That would only come into play when we get past several GB worth of invalidation. --=20 All Rights Reversed.