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 2CA05212B21 for ; Fri, 10 Jan 2025 16:10:53 +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=1736525454; cv=none; b=MSx75TEvHJHBKaQlt4WGD1sdYnArYe656qdKbEcdomCwKlmWkUuLhnioXTSJDfiprvopeHL/0H/q2eTaHBjSIVAHLeI5dvQppI/WBRxgqi/Npl5mIXsio4Bg2N32159eS19nixZlUapBgfVqOiITY+3ihVpu9z7uzzUl4z5emNs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736525454; c=relaxed/simple; bh=j+FkcpM6Zqd6WwrwE6unByXsxOxFo52laL0TvKkNGkQ=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=TVot5t7++NnNZvU8xqY+Vmz/QP9/pLn7iR+aYJCRaX4if6/xe39DVJjwZH3+GDo9D7nhiMe8wwZ8x2vPht2l6JzfURGwwA1nViLYzOw/Nx9AUspeDC0g766VeiopTNLP8RlJ3G5+K2jNI/UgWQFbESHoijuR96R2Y2fmWyCNcz0= 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 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) 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 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.