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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7F9E3C61D97 for ; Fri, 24 Nov 2023 09:56:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230375AbjKXJ4m (ORCPT ); Fri, 24 Nov 2023 04:56:42 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57626 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229668AbjKXJ4j (ORCPT ); Fri, 24 Nov 2023 04:56:39 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 0FC8992 for ; Fri, 24 Nov 2023 01:56:46 -0800 (PST) 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 35B5D1063; Fri, 24 Nov 2023 01:57:32 -0800 (PST) Received: from [10.57.71.2] (unknown [10.57.71.2]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 09BD53F7A6; Fri, 24 Nov 2023 01:56:42 -0800 (PST) Message-ID: Date: Fri, 24 Nov 2023 09:56:37 +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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 23/11/2023 15:59, Matthew Wilcox wrote: > On Wed, Nov 22, 2023 at 04:29:40PM +0000, Ryan Roberts wrote: >> Note: I'm resending this at Andrew's suggestion due to having originally sent >> it during LPC. I'm hoping its in a position where the feedback is minor enough >> that I can rework in time for v6.8, but so far haven't had any. >> >> Hi All, >> >> 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). 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"). 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". If B) we could move the interface to /sys/kernel/mm/large_folio/*, but that introduces many more banana skins than the current approach IMHO: - We would still want to expose the PMD-size large folio through this new interface and so would still need "global" or equivalent for at least PMD size, but "global" now points to a completely different sibling directory structure. And it probably doesn't make any sense for the non-PMD-sizes to have "global" because that would imply the THP interface could control the non-PMD-sizes, which is what we are trying to separate in the first place. So we end up with an asymmetry. - When we get to adding other feature support for the smaller sizes (e.g. khugepaged), we will end up having to duplicate all the controls from transparent_hugepage/* to large_folio/*, then we have the problem that e.g. scan rates could differ and we would end up needing 2 separate daemons. On the interface, David and I did request feedback on the proposal a number of times before I coded it up. I'm sure all solvable eventually, but I personally think it is overall simpler and more understandable as it is. I also agree with the other points raised in favor of "small-sized THP". Thanks, Ryan