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 DED18C61DF4 for ; Fri, 24 Nov 2023 15:23:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 724D48D0090; Fri, 24 Nov 2023 10:23:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6D3E58D0084; Fri, 24 Nov 2023 10:23:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5C2C98D0090; Fri, 24 Nov 2023 10:23:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 4C1F48D0084 for ; Fri, 24 Nov 2023 10:23:08 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 29789C0F7C for ; Fri, 24 Nov 2023 15:23:08 +0000 (UTC) X-FDA: 81493216056.27.2C47263 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf05.hostedemail.com (Postfix) with ESMTP id 1608F100010 for ; Fri, 24 Nov 2023 15:23:05 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=none; spf=pass (imf05.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1700839386; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xgpfuwKiNeAvP8r2s5OjgoEqFYvABSqvcc4cFzqqvP4=; b=rNU06HC7TAVMC+/51Ilyv2l+IM/PHGukS6GtdJ9Hgu1SL+EfWO73l4lux9CH/DMotOINqb ryMzYjQqbkfozhSHjRPdcg8o5r13Zit5tUEN9btC2NWrRF/eTOApN2YGT9gFXV8iSNPkbH 6jW4OOMED/voptVUJjwI3aVDAgqKyFo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700839386; a=rsa-sha256; cv=none; b=fq7oUbOit9+8q8fkN2RyfMJ7X86xL0dyfr7E+LQGzBu12GvCL5ADr6bQ9qgegFCyb4fUoN Q+0KGegYDFZyWGZ5T86/4GxA+rn0um3M40SL1HBZQWUKVxM5qxyQ+X8fHIOt+Ka03ZzhU1 rka8W56QfrfWdHldRfBEDtLTZ8la+3Y= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=none; spf=pass (imf05.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 63AEF1063; Fri, 24 Nov 2023 07:23:51 -0800 (PST) Received: from [10.57.73.191] (unknown [10.57.73.191]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3B04D3F73F; Fri, 24 Nov 2023 07:23:02 -0800 (PST) Message-ID: <9379cf06-8f91-41ca-98dc-0f57b486952f@arm.com> Date: Fri, 24 Nov 2023 15:23:00 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RESEND PATCH v7 00/10] Small-sized THP for anonymous memory Content-Language: en-GB To: Matthew Wilcox Cc: Andrew Morton , Yin Fengwei , David Hildenbrand , Yu Zhao , Catalin Marinas , Anshuman Khandual , Yang Shi , "Huang, Ying" , Zi Yan , Luis Chamberlain , Itaru Kitayama , "Kirill A. Shutemov" , John Hubbard , David Rientjes , Vlastimil Babka , Hugh Dickins , Kefeng Wang , linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20231122162950.3854897-1-ryan.roberts@arm.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 1608F100010 X-Rspam-User: X-Stat-Signature: qapo3dopzuwyye7jgfsj8dpf4so3hz3g X-Rspamd-Server: rspam03 X-HE-Tag: 1700839385-119958 X-HE-Meta: U2FsdGVkX1+Oj1c/QYaGea4H4WsYOEH97F9bx5ypysuWmQ9Qs3PIJwB2UUpxdiwcAvA/Yp272iGhw1z11asDy9p9JBCdsSAWjcUJ/zkpfnpGpfkixr90uKg8PmjSr8J6sRbUARK06l4XzmAEe1rPiNO8Dyirv0tBKDnRrv2ZOIuUztdMW9zUhVLj5x0NrMAKIVEL+SH045w22NAMk/FvkZ7edcyDzLKp07H1qgp4dSP/vx43imyE99qWZa4L7QZT+TErV1SmEPdCJcBPpgcy6Sh8buQSlA9ZXsKBH9TOIOaNtwXghMUxjLr6ohGhzBIpBO30q3GXTh6mmrT7dQT5ecX/BPtv8jiazt4bx6nEUWL1VY7qZbcWmEuolszml5VL+rAxG4oNkFIZTCOgqLKwaS1LZPu5IB3MKE60EudT+Ze+l9GnQgdvHa0qXXda0pnNhm6pu/JYWk6t/oK26GhZEc9LUk8cyd13BU2IcOVpY9fbY4P3Kq50uqQp9S7sZTHofszNYyZckaaRM0FBEbuKul0Cb+F/ENEmtBKVDqCB5pEkTVzpJa44O68TSqgq9liXdzYHaL9hMn/KkOogWldhqFfnU6L6fcb6b9TJIPArytLKUKVV4qchYRTO7P+7MzIGPm6310OxAwxYMhSWvj0LYMHhj0tpDl17+HcjIbEzl5m8+i5lLvseAFVNuG9O7uG20UMZxFr0pU1oa0OtTn7G1l080Zl3Q3Svhn0pX96C/D5DZI5OXNtimS0pnUjZoxN6IWCEzTCltr6ufmzRhbmiJw9CqyiXeSNRY7OUgVVT+7e9ScGenns457CkODcD1i7e5dd2jvGm+6iE8dVPXX8IN1HXib0dHUXVLkSEsWbSx7c2XrXFQpyz+fvnbOITnOMz0dUz58oBAN5y7FhOWMNWYMWnALM2FM0Tkz/HwGEzfsaxcVT25TVnCi1h3e3grBgWWdz2WSM7w/jVfblAQZM 1BGkA2pP xDK+S6bkmjRCKWXfFmLpTHXFA5mX1/6Lia5e849DzMIaLTj1I/Xa2CevNPCTBG5/AD2mszLqZ6qF2Tc5nwdNdrsas4FTBwQ7l3e12nW6DpFiVJV1WhS2tUzLCFSrT79+7KdfpjNE2jD8G1/zyFyWItsJHnqQ7s3vJ0G97JD20pxkTnqp+wY1KxrneD+/aHooRTBrdsSy/P2yQyNZkypr5CaaQkk0RJlU500zr 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 24/11/2023 15:13, Matthew Wilcox wrote: > On Fri, Nov 24, 2023 at 09:56:37AM +0000, Ryan Roberts wrote: >> On 23/11/2023 15:59, Matthew Wilcox wrote: >>> On Wed, Nov 22, 2023 at 04:29:40PM +0000, Ryan Roberts wrote: >>>> This is v7 of a series to implement small-sized THP for anonymous memory >>>> (previously called "large anonymous folios"). The objective of this is to >>> >>> I'm still against small-sized THP. We've now got people asking whether >>> the THP counters should be updated when dealing with large folios that >>> are smaller than PMD sized. It's sowing confusion, and we should go >>> back to large anon folios as a name. >> >> I suspect I'm labouring the point here, but I'd like to drill into exactly what >> you are objecting to. Is it: >> >> A) Using the name "small-sized THP" (which is currently only used in the commit >> logs and a couple of times in the documentation). > > Yes, this is what I'm objecting to. > >> B) Exposing the controls for this feature as an extension to the existing >> /sys/kernel/mm/transparent_hugepage/* sysfs interface (note the interface never >> uses the term "small-sized"). > > I don't object to the controls being here. I still wish we didn't need > an interface to control them at all, but I don't have the time to become > an expert in anonymous memory and figure out how to make that happen. > >> If A) then this is easily solved by choosing another descriptive name and >> updating those places. Personally I think it would be best to continue to use >> "THP" since we are exposing the feature through that interface. Perhaps "large >> folio THP". > > I think that continues the confusion about the existing interfaces we > have which count THP (and mean "PMD sized THP"). I'd really prefer the > term "THP" to unambiguously mean PMD sized THP. I don't understand why > you felt the need to move away from Large Anon Folios as a name. > Because the controls are exposed in the sysfs THP directory (and therefore documented in the transhuge.rst document). It seems odd to refer to them as large anon folios within the kernel but expose them as as part of the THP interface. But I'm certainly open to the idea of changing the name in the commit logs and being careful to distance it from THP transhuge.rst if that's the concensus. I am opposed to moving/changing the interface though - that's actually what I thought you were suggesting.