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 180EFC021BE for ; Thu, 27 Feb 2025 06:08:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 80FDB6B0085; Thu, 27 Feb 2025 01:08:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7BF636B0088; Thu, 27 Feb 2025 01:08:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 661086B0089; Thu, 27 Feb 2025 01:08:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 487666B0085 for ; Thu, 27 Feb 2025 01:08:29 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id E926A1205DB for ; Thu, 27 Feb 2025 06:08:28 +0000 (UTC) X-FDA: 83164695096.12.B9B008A Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) by imf03.hostedemail.com (Postfix) with ESMTP id EFBD920002 for ; Thu, 27 Feb 2025 06:08:26 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=gNOJHJvQ; spf=pass (imf03.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.160.179 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740636507; 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=VPz1Jtb3iDmlzLw3YyOfEPl0dmoA/8jm1qHrEBiYBV8=; b=w2yLlaYQsLb39dMCPsnNp93hEKPp6+YI0KPqtOsL0KL4rRkfRznhLskLaHBPNwX00AgxTX AlcYRka4Uch7naVhULjVe2N+JpjWSmAAvVSwtZUcu7l18lJO7uUzRAp2LU3QjPa+Jc0U49 Ys02z/FVV535TZDSBfkX0OCKVgf+Ozs= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=gNOJHJvQ; spf=pass (imf03.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.160.179 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740636507; a=rsa-sha256; cv=none; b=Cu0McGpF6gsLx4fcLz1t5dwlXc7Hw+l+VkFP/yXZx7fe/H+TKLBWst9r+Bd7kdRzOj7jx9 dzbjQIOK9/YjacT0liHsJcK/OSPLdRgaNmRUTa0+E0A6TbD69NHy5O8zsiES8BiEtDESfF AGThfZ2F7mI+n2IIVk2wWudwcDLqSUE= Received: by mail-qt1-f179.google.com with SMTP id d75a77b69052e-471f88518c8so3112821cf.0 for ; Wed, 26 Feb 2025 22:08:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20230601.gappssmtp.com; s=20230601; t=1740636506; x=1741241306; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=VPz1Jtb3iDmlzLw3YyOfEPl0dmoA/8jm1qHrEBiYBV8=; b=gNOJHJvQyQk1g5UlYHcRAolXxZJxyYJnCpOg8B6xQaceD5RCE7/T/c2/L0txai/Ycr BPtRFPMXRd0mRwrowQ9MiQMSbRUBoVR+B8892Gq6NVef9DUMYIrlj8H11wmiC4ygLEJX eGuI5AqkP92/cUl9lcd2o6xAJ0lc2zV8aLOhz7in8Vmhe+gR5TjV8zPWjBCKnObjGMrW TYpFYfGTb9661wVrIOsF4CeD9Ynq5dpAbTB0IoHgj37aBR0NeweND/KLcO7CeJJk9IQV 2I+N+qQYfkcU6hwORr0Ynh9yHnkjgXcZwQG+iOcfFEgvjOixkbKlDEyfC0H9z8ckegIW nWig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740636506; x=1741241306; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=VPz1Jtb3iDmlzLw3YyOfEPl0dmoA/8jm1qHrEBiYBV8=; b=MINN3DPLz5zYT3OV+nHjUm3H8AXjwEL2eDkDr6uvYV/ILA52LTBode8/dPBnfEDOl2 5pHuf2KeBahv7Iaow+7sMDoxUGmEXswMd6GdyNJtTduvv/hS1TbLnvu6DK0dBWeat/2u Pb2bvw2OtGebvQeQrejzFVOmxGqD50zLLAmcTUiI/RLcfRhbQwddr/dVNZxBls8zCnDj pU7oZzVbmlxO4h8Blf1Kfe4P19AdQAOmG8e10HER9MFBYMkkiXsE1NwGnIcTtUmiy9Vh RT168AcL8F7Vc/oVaGY7CCUWZygbm3F79LGEPVp6abZwHOQxuPTn58Y6S/pjLMytT2nV YkMw== X-Gm-Message-State: AOJu0YwZNdbPFRlC5+t8I5Bfm8/nbpwFuWTStPNyhErkYDaeX5ZTxLQo dsqwVJH79UT71mEGI4IYea2oS3MHUQVnfn/HVCwv6Ub//kmbCZJff/u052XtvRE= X-Gm-Gg: ASbGncszozzXfMQIp2fKpGywA1vKm5mC6M8gdenVueAfdYd/QEcYHwPghYSY4wbxRv4 zMpepGGi+s289im0kh7mXZRdkUrir+Xo3JJmOjijoTdX8N1BGQjlDQ0vIbe4uHCbK5ok8gOs5gA Dxy15iJ0pdiiSZn44YVzT0T0rUlwWnlks7iia2tjojEQ6JJhIS0umKLgWIJsXpNcmlsSV6yFazY NLHEh9E4QRIDcxS/cIMdSZIobDWR0NF+GGTTW+19TVYHoRnIiA3dFxLe0rvSZRT1VvPuBOB8AvV BhP9PIVMyucBsj9wrsRheN5/ X-Google-Smtp-Source: AGHT+IHh3l/pbd4U+HZO31M9X7egjzLQA2am+j8f66WkAfpl/b+8JFLXkEalx8BJVXBHXv/+SxiZdQ== X-Received: by 2002:a05:622a:24c:b0:471:ef27:a30d with SMTP id d75a77b69052e-47381365f87mr79384461cf.40.1740636505919; Wed, 26 Feb 2025 22:08:25 -0800 (PST) Received: from localhost ([2603:7000:c01:2716:da5e:d3ff:fee7:26e7]) by smtp.gmail.com with UTF8SMTPSA id d75a77b69052e-474691a1f2csm7429221cf.13.2025.02.26.22.08.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Feb 2025 22:08:24 -0800 (PST) Date: Thu, 27 Feb 2025 01:08:20 -0500 From: Johannes Weiner To: Qi Zheng Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: CONFIG_PT_RECLAIM Message-ID: <20250227060820.GC110982@cmpxchg.org> References: <20250226183013.GB1042@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Queue-Id: EFBD920002 X-Stat-Signature: aj1k5b1651nrjdws1wwiupaipadhc76d X-Rspamd-Server: rspam03 X-HE-Tag: 1740636506-738262 X-HE-Meta: U2FsdGVkX1/pLaL6nOEkFd3HUEKP/uvyDazlGByVCPatP/vi3qYQqARlQoEJzrVmjoEXBNpdF1tavYVAsCM0muknfxwH8EJtuA5qT4grh7b/XQmCd8cDyHzIshu/5Ivb/JYdJw60ZdNmnMgdRdEkITlJC1NFwrY++dUlQkgT9xxh3n6xDG7JaHO0dhyXfll6S4/05/ynLmiNDRD/z9fjgOLwRnQncOwR1KoTRjtOornONbsVuuZXnXnrdCz1yxMriuxkTI2RIKFvfhtvXGkR1SxtC7IM5BXfvFZohe7IONVmfUYuEOzyn56WK4dAqP+FylRlBVOdWWidMtn3wgZo0fS+05eZ39lYFvcZkaH5I5OqTdA280LnDsFXMM236YSHYQut1EqJVUX3ZkDjwlwX1yjRsV1Fqh69Tqjk5NiIgKawMF0ruyx7vb/jmyfJfk47wOGZ40j3hExMJvVmSr1sPLKkWbMuqncx1GvEv3desw83pylcyL9QcCww9QDNoIg3GJadn8sjBfEaMRjNn9TJ+Q2uYL3TL8ey3x28bnmIiDWM4RhlKvbHahPrJ1IqJPxGQKHB2mS7u83Ovn8IJJNfu8d8vGqQeSrDCxkicJ/OUqxGJxxdV//qdo6IqkbbWdnWoA0so0x9WM2gMewbTC/vw5n7LXd7HZK6EegKj3rVQ7Z4zOSV2YwVFFCo/H6RQh03S10CzHbexEkuAiub6TXuRMp7ptioTchM5j7Y5+evH2ENx8ifp6bdAoNa2f/mfnaOiBXV4/PyAHpkUryI4I2/F8WqHOca2FuoJh5h/lGAQTOohhDSjsTO7Xsxt4yeCAv5LYyXwespwW5m+kIC4mh9uqH3rcvb5ft6M8LsbvCbp8/l7MQ5AId2/uQYETvvF59BTBjPiKWXiHnI6xcjO7DbBOK2BnuOPgdlocHH6yXJze+UmFRrSBXlSVaICchDL1iHrlZNU7LsIrRe4j6QESH 7o980PlU k0NprbhkUodCw6HPluQKM4m1692P1/3I7jSPcpWsySPlkWuSpdUdRy1jLLOITxMiPynGayYytzsCud5uruiDdKRycN9NZYG48tyXG2I6JCZAaZ9CJCbvgu++ri0lUWv5A2mi2IMiRNQJNx55QLP7bVEqOGlt2zt6JG/i4NoZAqA5n2jGrKvonJw6I+A8OJSRBfTbufOutNENbcBCCqSdHBqwB70ISPJP85z7LOxQReVXBSAaYsI/NmuSr8g+59tcZkmwDEpIbU5WarQ1KJq+wettJ6hz3FEWxUlFC9C6eo3Fhfp0wC/2kn9ljojgnPSkrgPZhtMxLzwr5yobuIgPnrRf50MuH01PkkujYjM87ILmKxDWz5FJstYh2apYaeIwLuHR4J0wZVMSPsa1Q/7bihl1tA4SLNJNKjfAZlHYLz9Xwol3bFvYN6WB+LD98mAvqQhKWLhQoghEONXKVJtLwfP6j/97Ium4J8vC+VvaoOYGXPEJKNc4qQvmmhpC8FHXa4tVe5USwK7yzJvvKGmM+7jwW30EhQetK+dosuGGhEGi+FQM= 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 Thu, Feb 27, 2025 at 11:04:51AM +0800, Qi Zheng wrote: > Hi Johannes, > > On 2/27/25 2:30 AM, Johannes Weiner wrote: > > Does PT_RECLAIM need to be configurable by the user? > > The PT_RECLAIM will select MMU_GATHER_RCU_TABLE_FREE, but not all archs > support MMU_GATHER_RCU_TABLE_FREE, and even before Rik's a37259732a7dc > ("x86/mm: Make MMU_GATHER_RCU_TABLE_FREE unconditional"), x86 only > supports MMU_GATHER_RCU_TABLE_FREE in the case of PARAVIRT. > > Therefore, PT_RECLAIM also implies the meaning of enabling > MMU_GATHER_RCU_TABLE_FREE, so I made it user-configurable. And I just > thought that as a new feature, it would be better to give users the > ability to turn it on and off. New *features*, yes - something that has a significant enough cost that clearly not all users want to pay for the benefits. But it's hard to imagine anybody would WANT to keep the page tables around if they madvised away all the pages inside of them. It's a great optimization, what would be a reason to opt out? > > diff --git a/mm/Kconfig b/mm/Kconfig > > index 2761098dbc1a..99383c93db33 100644 > > --- a/mm/Kconfig > > +++ b/mm/Kconfig > > @@ -1309,16 +1309,9 @@ config ARCH_SUPPORTS_PT_RECLAIM > > def_bool n > > > > config PT_RECLAIM > > - bool "reclaim empty user page table pages" > > - default y > > + def_bool y > > depends on ARCH_SUPPORTS_PT_RECLAIM && MMU && SMP > > select MMU_GATHER_RCU_TABLE_FREE > > - help > > - Try to reclaim empty user page table pages in paths other than munmap > > - and exit_mmap path. > > - > > - Note: now only empty user PTE page table pages will be reclaimed. > > - > > Maybe keep the help information? I don't find it very helpful :( Which "other paths?" It doesn't explain any pros and cons, and why anybody might choose to enable or disable it. The Note repeats what's in the sentence before it. Maybe I'm missing something. Could this not just be an #ifdef block inside mm/madvise.c, instead of living inside a new file with two new config symbols? #ifdef CONFIG_MMU_GATHER_RCU_TABLE_FREE ... #endif Is there an arch-specific feature that it requires besides MMU_GATHER_RCU_TABLE_FREE such that only x86 supports it now? And why *does* it require MMU_GATHER_RCU_TABLE_FREE? Documentation/mm/process_addrs.rst explains why you need rcu, but there is free_pte_defer() that THP was using long before x86 needed MMU_GATHER_RCU_TABLE_FREE. It seems to me if you could use that, this feature would also work fine on architectures that do not generally need RCU for flush & frees otherwise. So is the main issue that there just isn't an explicitly deferred variant of pte_free_tlb()? If so, this is a fairly non-obvious dependency that should be documented. It would help somebody trying to port this to a !RCU mmu_gather arch. And I apologize if all this was discussed before. But if it was, the conclusions should be in the changelog or in code comments. This is a very delicate synchronization scheme that I think deserves explicit documentation somewhere.