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 2F505C61DF4 for ; Fri, 24 Nov 2023 09:56:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A96BE8D0063; Fri, 24 Nov 2023 04:56:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A46536B054A; Fri, 24 Nov 2023 04:56:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 95DBC8D0063; Fri, 24 Nov 2023 04:56:48 -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 854A46B0549 for ; Fri, 24 Nov 2023 04:56:48 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 640161A0D48 for ; Fri, 24 Nov 2023 09:56:48 +0000 (UTC) X-FDA: 81492393696.27.52209EC Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf15.hostedemail.com (Postfix) with ESMTP id 96D37A001B for ; Fri, 24 Nov 2023 09:56:46 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf15.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700819806; a=rsa-sha256; cv=none; b=soCjTD5Dxd+tCVx5dqObUsxwJ0D+mFHSICzVOEecgOwhcp0rC55ega4yn9uy6CGRbCUqAL Dsgfc2HH1mWVNI91j65X7YgagdX1VXa5nRV4mfPNQ8CI/+IcGkn97AHfgPaqrwXVQuUEHS ozOVG3khI8WW71wGkPoAu27UN2p2HrA= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf15.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1700819806; 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=8C8Nq1dEkRZHOjdm/PeDcGFa0rd0ECatcLzmSNvX/IQ=; b=umM9LS19Y9b6bCMtX9CtTD1UG1/+npnIr1IhkGgeChkyyT/3hN9G7npbMCQ73Sbx9Eo9NJ g7ATXQPc4wgbiE6AM2Dr5UDf9OqQStTIF/mvUx7DspYdQV1rPf0zEFRV3n2kqaANoR8IW7 AXCIEB4zx64X3qjhkVqWM1z6vL96MJs= 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 X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 96D37A001B X-Stat-Signature: aquwkmiua16z4ccqb38e81ewynkfbem3 X-Rspam-User: X-HE-Tag: 1700819806-760710 X-HE-Meta: U2FsdGVkX1/lXKBHo9nvIn6+Kh478LzndxF9jaifhMIhFptW9n1Q65d2CcHoygYON8yNGjSuAZHXUPQ23VBUH/smOd+Lv3v+w1HB7+3x/VSG85dlayP8tt9i3PF/2chmt+/r7ntWau3xx0wvoME1Yu68W1QD1WjSh7S18ulgy32S2f/K4pSkX+1xwLO342vl4a8a7MSSfNQ61ThIAl7SAUUzNiHy4MiuQCEtBWE1w4kAwOggNv8fQ4bAECFiWvSV2UYi0psvxuV5zNRmg/w2q4ih6rhT0gnCes1doR7lJ10ujZTozyhoe2gSi5gdwh9iCAga+szIy+GfRPf6DL3cp3RCcfrqEcJ3KhHq5lffe46FqVYr+gE7+io3okBt/eWGLjKG1vd5QOH776/D70Wibn52tLrNMMCfrlp2xtKorG4jS3h3FdcI56aswGzQSTHYa4eqZPgpcEfo843hI/9DWL86YlUO/rxpNy14w8a3TrOqmvRAI2488NkTJzC7Ibrzw4RNqXRKA9Nrr7LnjS6Az3UjKuqFEzHH3OwebSJmayDqYtgMIaBnHdELRwaquyOvg000sBuk1YP0QqtnmJsipiwBjqgBbUFrkm1Gr/HJ7R4iA7h775OAEkeNMmSQtd4RSyrs/JrBlSFZmuC2WxUdgYyHAPkU0mjLy11R9ap85zg3ecJxVIlwIn9ljznNbi+lJ6c673/zvmr7d8tkGku09vJdrOKdpIMgr9B8AeglAYsYmqFFWPlWiCeraK1WdzeldtM5eyze7XmGd4cl1SV99giBvm16hmnmUIT145R3+CMR5iTMRZUBhSQpIgdtJMOd2183TyrzlWVEq2xiIndAxkQZ1lT8a9YQC9qYz1bSdBxPB1wlhmVsNPK3ikaGueQBdDle7l60WO/limrJ8ItYIzErRJ5doebpiFEJEBv/JpTNWeUmspu8K2Xev0nZOYX65JU8i0eDYl9evwfTW22 igQkLV8F wxnSqJxrMeWMTF9OX4EjH3X3aj8trs8lM5Z7UL28kq+3k/kwq6VOGFCRI0UE3id+Gw0Hz2ZuvYvVXbUSZAg+IRDDtFGAmyTVqMryUITgxCqaLOlrRltidKQv3ldB0kCHiTItoNujmod0rz6njEHJy8nfI+7N41iovqE1E01G2NECxERwuwZund7ykw11foAZkkP2ZCxr1WsKc0bVdX3Bar7tUP6pszxjah4k0 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 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