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 52797E77198 for ; Mon, 6 Jan 2025 16:04:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C72FC6B0088; Mon, 6 Jan 2025 11:04:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C217B6B0089; Mon, 6 Jan 2025 11:04:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B10B56B008A; Mon, 6 Jan 2025 11:04:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 938C96B0088 for ; Mon, 6 Jan 2025 11:04:37 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 0C99E1A1750 for ; Mon, 6 Jan 2025 16:04:37 +0000 (UTC) X-FDA: 82977499794.26.280357F Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) by imf10.hostedemail.com (Postfix) with ESMTP id 58C3CC0005 for ; Mon, 6 Jan 2025 16:04:35 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf10.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=1736179475; a=rsa-sha256; cv=none; b=hGg75+azoinj9hqLktRn2Z9XSNVKvPFAKn/EZLVyMslnnUVGPKgI4LFlrSfEC7TRBLyeEx KcGwBSJ0nJBNho4nJVonoe7tumXZ3qtG1mAOHTR3Lr5iV8u5lBdsSb1MIrgbYNj560yRrd A31YvPSS6oxQByOvzZpmQ4k1+p/v/m4= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf10.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=1736179475; 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=sd2q2XE99BePGsWQkrJvdr58oKO9uUA+6V1MhdUhjwA=; b=nOrVf4IFDdtnzizSDWUj9aBpaa0OPBuU7QNL8goDII+Q+pd7RiHIgMMzcNuZtMVVb7sY/0 Vq/2KETlp3LC8fTp70RJjRAxmduYxbhuY5wiaFnfcQPxt2ld7RZRgSsG9B33QxcgI/X01q E/dLLTj0wVImgquDNqrCzb/Pm8SzamA= 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) MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 58C3CC0005 X-Stat-Signature: 9359dgkf1qi3xqyqta6e3m1gbqk8somb X-HE-Tag: 1736179475-938854 X-HE-Meta: U2FsdGVkX19YrTrU/mK5aO2fy72A8fHL0I47BXdB+kmxOi/lfo0wS+jOweIJto/fzSMjYRONChxV89s/DTrccl+1t7lg4TMQW3qHJcrijVl/eMp4fF1T5jxJjdF2fHS6AgczhUKrdwMYlQ7CRALp3O3Nt96ljh3Mj09VDKvyBsb5ldQ3JT5QFgzqWO6eloBiPOdk0WjfsD/qQWrDkBjr9GGCiyXOh36u/d35uYHDI4oMhl8fxpaMfaz+Env2/upefUmhwC5CLrj44NA8BXrLuv0Of8D/hdbiZ9thaUFZ8avBnRHmAWituJkLi5RBFv4SfQ2NQ489gfnTvn+ifMnPy836yp2Fk2eF1IODzacIl2KaP8H/yxCe4FsPxkQ3Db3tMn8jiSu++NWMtG8qzsYrQ38oRHvXhIeyIIWepIXtO8ggPsOLm7Tc67K9NSih7jflIAxQKFFBRkJg15e9GsB+HOprnRaOginJhUdMT5ZJpmezm+NksDe0uyro8/vafNU/YhUty2/gOPy5qJiAxDecVyeHuGevljvHeJepq7NfrdEt+ywhddb0XDrFEEorneFO/1BIL0NYFkkZUrLfCzXb6UvhwyvwoLz17ldPUzvfGyLghHkAwsYCDq9kXToWMke2zcnvfefi7QgGFttV6qe8kPwXIiBHpMHGazhk8EFsqDCpXbC0OxzDB8hdYgm/gM8XBX1jAQ9eFhM69RPs5rxS/gbHX8UqeZ8t1h4934P/7i6ehsilAgV2kCSEdWe/uGkB40razC++dc6A2lP/hUkakHl+p7B4b29buOyJ5m74BkewuC7gcTJAbMkPqWISAHa0Ui1UtUASIqB0eM6cxecE6xAn+vWfnNWuzVTg4hgKuNkVeU1BQpy6+210OsA21x6xKp/NhmqoJQZH/XQaZUb8K1obaTwKbZ6cp9pgABae+IRIEgoaluWXwT2n2c8pP4/+G/fPK2I+kLnbQLWisxE ICdAHUSp efkUjXuVdQn8YcjffwIMHTqbfp+ybc5p4+RSHL39lsCuix4aPRZNRbUqew9N+rrT0HhPadCwezwt5L8F02meZ4G+zWd7kkvXJPAXevgBv8LXYo1MMf/8zxsKD/tHorQW6aacJB02PuGhh4TvuPfcOBaWl7WsktX97e0BqrsWkCgGwely6JucK1S2xJBLnxmrM5z4Iwr4it7t+sDJNc7JOWIGCWk4QJ611YQ8oV7XNycYa4c86+19XsAH8X3iUOddm5bVUbxL7jiExIBAPpAJqDohlBKbGSkxz+LjW/cZgBxLjBxr+tA6HyJiQa6GiDMSSU1Nbomd4/CSYAiweRIUBQ3ZIhYqws0+dA13QkphpLo3Ak5g1T20FNsBMmgWskeIzhxovepIcb1J05hI= 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 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.