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 96155C0219B for ; Tue, 11 Feb 2025 12:10:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D34FD6B0083; Tue, 11 Feb 2025 07:10:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CE4716B0085; Tue, 11 Feb 2025 07:10:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BAD166B0088; Tue, 11 Feb 2025 07:10:39 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 99CC96B0083 for ; Tue, 11 Feb 2025 07:10:39 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 495E71C86CD for ; Tue, 11 Feb 2025 12:10:39 +0000 (UTC) X-FDA: 83107546998.29.BD0ECF1 Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) by imf14.hostedemail.com (Postfix) with ESMTP id 79742100013 for ; Tue, 11 Feb 2025 12:10:37 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=DysO2V+i; spf=pass (imf14.hostedemail.com: domain of jackmanb@google.com designates 209.85.160.172 as permitted sender) smtp.mailfrom=jackmanb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739275837; h=from:from: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=1N4BjHm0w2ueghlCuqmC8WLv26kWSsqWLwCdcxZhQnM=; b=igUc7xlaNWJ/E3cyDe7EozVAN3u5gBhqR5OJtUr0QlM7u2lqGWBi/7dsIwlSogQ2ok6Q36 tDfLoVIcYkLWe7r3bcMKl646aPrBsTaM0zB9JHECe/irEafmomwSTzu/o7hcKzxesIEtDt 6R/UWtfRl6lfE+14ue2G0IXvdB9Sxgo= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=DysO2V+i; spf=pass (imf14.hostedemail.com: domain of jackmanb@google.com designates 209.85.160.172 as permitted sender) smtp.mailfrom=jackmanb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739275837; a=rsa-sha256; cv=none; b=2UnjqxW8oj2BxBMzWwG+7815eoAL9wXmC1MrUxig/LTw9jBXoas7JsxiAdIySJmEMPeuJP /yLGx8Zd812g8lrTdLSrGnIwxItvGZYPYHZ3/KoQdBOgbyiazoNF0qwTLkZ0Xp+61YnYU6 4PZC4f3EL/OZwU2d95wF/eZxfaEYUuw= Received: by mail-qt1-f172.google.com with SMTP id d75a77b69052e-47180c199ebso227771cf.0 for ; Tue, 11 Feb 2025 04:10:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1739275837; x=1739880637; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=1N4BjHm0w2ueghlCuqmC8WLv26kWSsqWLwCdcxZhQnM=; b=DysO2V+i4K7a1wzG22ghhQwdvE16LsnPvHfXEqeJy8NG6l+lBs/rqsXTkNXiyPp92S FtoLOeEmZaqBYJTor8Z9CSFyDS8ZXs5JMoE8eekyjSKuJ02sVRY688vpk+VqavVFo1g0 ux0kO3UF08Hg8E32ox0lCbf08nYRxmx+1gYLtSDEolg2fflig/aI7GmdYhJC1RJ+R2VW Bv6phMFitbhMIPvUS5ok87HcnXzHRCA2cOS0v1qMoMDw7bb/jBXHuPz6kRjSbZoATJdN qKJ1ofKg/Mqk11OMz627S+taSyz6Fxe2GpEBdBqg9n9vqGwdXztcuAgEUnKlZkB1huf8 qqgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739275837; x=1739880637; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=1N4BjHm0w2ueghlCuqmC8WLv26kWSsqWLwCdcxZhQnM=; b=T7W//mt13kgvt1MdWoOvb2bM+4a2+T1Tq0Mrbuuc4FtDQmFB13xUfhpa8tYuJC5iQZ eu7FoAMP4Sd72S+E5FS5W8t5yLy+lH9bH7oVn6xUwg2xs7pEK8W9wh7uzHQLOVewV+6D RxDqx3DGllfXOnxDX0jSnmyCvnts746OvO6o6Pa4hR/cL3uCmozVwnNTx0n7ErXAmlGa wKAPQzjc/dF6Cb0dK6NICsneil0CpR5se4qjeY/yigK9nuv6m8e5Jw/42MFqbv9eUY77 A194QGOQi839K0aUnR5a/p8Q27Jblsr2R9cGllXDL8MNRKdmZ9Ql4EWCEGlCH/z9OtFP U8yA== X-Forwarded-Encrypted: i=1; AJvYcCW18iRokCTzCZ31n8gd+NJz5opHBznKiUg1GZMCLMFbzvxjLMY8/rxIC73ck1Qy+gHsGS1VM5pGSQ==@kvack.org X-Gm-Message-State: AOJu0YxHJyaGir4UI4742QYr8+BTnbi6ibH6k1eLhhwdyaJ4VV+kgCjt ybAk3KpVMwo6gpLo8PHj9PZgrZjHP9u0vrHO+NM2OD+8gX325UYjxuQvynubwt0G1PjsbUP4pTo VGU6YhzUdkah9qsjVJC21SM6otzDh2Qx7Q957 X-Gm-Gg: ASbGncs5gz+quKh7zM8/jGnqs8uLbybYEWq8e/HeZUvhnPn5nU6ZJPopsDQmx4Kz8P/ ATUUAyNnFrYRQmHMrAJc494Ecb8qqwO95rOPNLvvAEyYBoHQWq57mfojW+zNY5zvDyDJvTNj64V D1aE6vteG5XjWAIGUXR9s86m9ZHKY= X-Google-Smtp-Source: AGHT+IEQwEibAWc+RRxuuCdpPikFutJWVyXCzGKs+LngcPsqCNYBwJbz+eXEOrOLxm9bhPvIWlaknhQUeYYoGDpRBGw= X-Received: by 2002:a05:622a:24e:b0:471:92af:bf73 with SMTP id d75a77b69052e-471a24015b0mr3512441cf.22.1739275836415; Tue, 11 Feb 2025 04:10:36 -0800 (PST) MIME-Version: 1.0 References: <20250206044346.3810242-1-riel@surriel.com> <20250206044346.3810242-2-riel@surriel.com> <20250211110721.GF29593@noisy.programming.kicks-ass.net> In-Reply-To: <20250211110721.GF29593@noisy.programming.kicks-ass.net> From: Brendan Jackman Date: Tue, 11 Feb 2025 13:10:25 +0100 X-Gm-Features: AWEUYZl1qEIZlSom7v3otMg44tgV0viN6Er_o6RhnpuRLrgH7vOxr6PrKq5XL4Q Message-ID: Subject: Re: [PATCH v9 01/12] x86/mm: make MMU_GATHER_RCU_TABLE_FREE unconditional To: Peter Zijlstra Cc: Rik van Riel , x86@kernel.org, linux-kernel@vger.kernel.org, bp@alien8.de, dave.hansen@linux.intel.com, zhengqi.arch@bytedance.com, nadav.amit@gmail.com, thomas.lendacky@amd.com, kernel-team@meta.com, linux-mm@kvack.org, akpm@linux-foundation.org, jannh@google.com, mhklinux@outlook.com, andrew.cooper3@citrix.com, Manali Shukla Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 79742100013 X-Stat-Signature: 135f66ouj1kumff5nntos1jcirdkt1jf X-Rspam-User: X-HE-Tag: 1739275837-968098 X-HE-Meta: U2FsdGVkX1/SVaYiJfBgNRbSXdPqilcCF6OLpBaMD5IBYZO+8ipdDWtcgUO5DfCdZyd9HUFQWft4awht/yZzA6zrMItLSXuBH660OEGW83RJ/3M/ikCy6ob8dEUA3pk1chCJ4bA7Xs3sfPtrdwfIlsk9GLBnT/ZpVl6UmEoLb3Mqq5m2L+0qot33UHDoTVYT8se6kBRpQ9dTsmQeG0Q5+p+L+R6SSPrHZVIQpeMPTzjVzlEc1bpBt/8FI0O7VQBcnYl4kp5GUzTcTKmJmeRnorlaJybYCoie7EZeQfgPdOOspM+ULtH6xC1m7GHWAZPHo/1ZEI7U1KutrwBzhUzp3cFPeeTwKPPaIh4EAcLTfdFnkDF8QD/SNDAy1AAxauMY4bgTphjYU3qewM8yTqfSg4QyVPcc0F4onzxcH1M/BTx8nLxS6Y8VkG3/eYyOfgEUO3od4LYBbZyZEbU5O9CCOSVRBRBgFcRRw4/DpQOK4BMU+8yvWqFSSHgR1+WrqTKwPvSDikF+OFLv2RoWyb4a2xbe0QdTzkzxogxNxya2+wgCJWVVLyW4NrVM45NyylIFc6yIG/z4fMurAQd52c3QAKkVRspnRv3+vlBpWcE8gRe4TNuFJ4ilGUHrdAqa0EImPHtnaXAQcDUvMfmt8BMWCpKuMX8FSXxmOCDEdqrTF2Ngh7WuZFzUjL60v0njPl/kk1GYmRZ8N5WDxJlH/3xUEL3C/3NLDUtiSSenEHXE/SxmB+8yQo2CmcQhGQLRayUoe2HSR0KtNZyDXF09hR/zD8Gk0XnlHYZQ2RqZ1cDLc3e7ZFVsig6RMdDf5yfmC7AFh78U8r/tB55jIRSZJDsbOp9pNaYTxmNehn1HGG2JLxAMIJudz0k+aczL3wA3Llac//GP0a/LUrnIHHPeT94NpRCVDmZ/vug1AjC2K8fHuncEyit9JFrWQGwmckPH3OwHuUKsmXqH7dbeywAv/sE cilO10Xm mTVdiBYhd+ySJ4gFlNt+B7xJ4o6BunJr2Q5bbDCu1E3M4Co9Ot4TpWcY/rK0L6s3OAgRvqXKt0fvKjb3+ordwFSBPQ/dXF67X11AUE4ew4o9uXbDqz/sFxL5x1hH0nj6sRzwk7KcOmM5wgjftlh6SFhqcOZeylpKbc8ybPW9u7jKHzUUcF+uH/PQGgf9BgN4+UEkrM746h+xOWUipF7PRmrCQLvYJRDuR4BrEBtVMx1HxXEDtupdVktapuGBF85MbHUcY4Gq8ZDQKAl8amIIT4WBiEI0gV2aZU/vo0o2PGxWKv+PPL+Y00oMc6u4plz9AZZt96aL3kIjxuLK6w+mOI99dIqcNdHWrWvPrzAp9INxg92xpJeosMr5nHA== 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 Tue, 11 Feb 2025 at 12:07, Peter Zijlstra wrote: > > It would be nice to update the CONFIG_MMU_GATHER_RCU_TABLE_FREE > > comment in mm/mmu_gather.c to mention INVLPG alongside "Architectures > > that do not have this (PPC)" > > Why? This is just one more architecture that does broadcast. Hmm yeah, I didn't really make the leap from "doesn't do an IPI" to "that just means it uses broadcast TLB flush". In that light I can see how it's "just another architecture". I do think it would make sense to be more explicit about that, even though it seems obvious now you point it out. But it's not really relevant to this patchset. > - and while that's being updated it would > > also be useful to note down the paravirt thing you explained above, > > IMO it's pretty helpful to have more examples of the concrete usecases > > for this logic. > > Look at kvm_flush_tlb_multi() if you're interested. The notable detail > is that is avoids flushing TLB for vCPUs that are preempted, and instead > lets the vCPU resume code do the invalidate. Oh that actually looks like a slightly different case from what Rik mentioned? > some paravirt TLB flush implementations > handle the TLB flush in the hypervisor, and will do the flush > even when the target CPU has interrupts disabled. Do we have a) Systems where the flush gets completely pushed into the hypervisor - xen_flush_tlb_multi()? b) Systems where the guest coordinates with the hypervisor to avoid IPI-ing preempted vCPUs? Maybe I can send a separate patch to note this in the commentary, it's interesting and useful to know.