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 57E0781728 for ; Mon, 6 Jan 2025 16:03:31 +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=1736179417; cv=none; b=mJRZUd09QYOsHr/yUtlXYvkFV29TCIppj/4fIUSfDmRsYBD5izv1ZCbrFjJ/gtB4ggSJ/+WEUXJA3Lk71etei7uJMy3pSytQGbnImSXmBNFTPxmcvceOawV3+NTAl7iYYoKT2hGmnGzPMz6O7/SAKjNM4o0rsSRxzw4WGFg47/8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736179417; c=relaxed/simple; bh=sd2q2XE99BePGsWQkrJvdr58oKO9uUA+6V1MhdUhjwA=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=pXPP/90Pr7lsXfKOChK3o84Jz6mD/PQsA8iX/veUTo6pfpSOpBT93sX90BWBTUPfXgv/7lsRF1MD+YkkJPQ8C+wuk6+7ZqmNLwgWcUr4Wr5mMRxL1Mi+9hvKPNy29E52VfGhgRgs/ZCHvhm7BWmq9cYeZIoIFOO5Z9JpnASZVc0= 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 1tUpZa-0000000075Y-3zdb; Mon, 06 Jan 2025 11:03:22 -0500 Message-ID: Subject: Re: [PATCH 09/12] x86/mm: enable broadcast TLB invalidation for multi-threaded processes From: Rik van Riel To: 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: Mon, 06 Jan 2025 11:03:22 -0500 In-Reply-To: <6A40E0A3-CF69-481B-92D1-F86581DC3441@gmail.com> References: <20241230175550.4046587-1-riel@surriel.com> <20241230175550.4046587-10-riel@surriel.com> <6A40E0A3-CF69-481B-92D1-F86581DC3441@gmail.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 Mon, 2025-01-06 at 16:52 +0200, Nadav Amit wrote: >=20 >=20 > I thought about it further and I am not sure this approach is so > great. > It reminds me the technique of eating chocolate forever: each day eat > half of the previous day. It works in theory, but less in practice. >=20 The PCID space might be just large enough that we can get away with it, even on extremely large systems. Say that we have a system with 8192 CPUs, where we are not using the PTI mitigation, giving us 4086 or so available PCIDs. If the system runs 4k 2-thread processes, most of them get to use INVLPGB. If the system runs 4 processes with 2k threads each, all of those large processes get to use INVLPGB. If a few smaller processes do not get to use INVLPGB, it may not matter much, since the large (and presumably more important) processes in the system do get to use it. > IOW, I mean it seems likely that early processes would get and hog > all > broadcast ASIDs. It seems necessary to be able to revoke broadcast > ASIDs, > although I understand it can be complicated. >=20 Revoking broadcast ASIDs works. An earlier prototype of these patches assigned broadcast ASIDs only to the top 8 TLB flushing processes on the system, and would kick tasks out of the top 8 when a more active flusher showed up. However, given that INVLPGB seems to give only a few percent performance boost in the Phoronix tests, having some processes use INVPLGB, and some use TLB flushing might be a perfectly reasonable fallback. https://www.phoronix.com/news/AMD-INVLPGB-Linux-Benefits --=20 All Rights Reversed.