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 ADDB4C3DA4B for ; Wed, 17 Jul 2024 08:29:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F09D86B0092; Wed, 17 Jul 2024 04:29:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EB9CC6B0095; Wed, 17 Jul 2024 04:29:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D813E6B0096; Wed, 17 Jul 2024 04:29:11 -0400 (EDT) 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 BB6616B0092 for ; Wed, 17 Jul 2024 04:29:11 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 5A064141753 for ; Wed, 17 Jul 2024 08:29:11 +0000 (UTC) X-FDA: 82348569702.19.9B6B4F0 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf30.hostedemail.com (Postfix) with ESMTP id 412C580022 for ; Wed, 17 Jul 2024 08:29:09 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=none; spf=pass (imf30.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=1721204929; 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=W0SfUOEHOGLty+4wyajL2eTSdZQfkf8nFwuSeZoDb04=; b=n4t2iOUGf013DOyVogBtHo3XnFzqVgQ7jFWcLf6p0/zBUGmNPbahVrjZLmOds52ht1iLCu 5OMzeikLZCeQVP1NGUM1zgHKtP4lCkJTemxPw7L+UswnDO3V4mVw1CiBzw8MIuwFdOyTuv bmHoFnFNbUvUebCh/OyxEgppObw3im0= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=none; spf=pass (imf30.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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721204929; a=rsa-sha256; cv=none; b=wZh+HHxsTTeP4pZVgeAEedjMaLujQ02t3itC026tP1ZIRrkN30xCOWyJIqmozj7LttHJTs 7RHETpaVZSM22jL/cQE7VrH//uJpQuIQqYvs9VJ31LJkV471RlUkKAkIlbM+ogB1cL4w02 KMtFx/ngpDd/sMN3Ug7aRA2A4Ni6e9U= 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 7D6E7106F; Wed, 17 Jul 2024 01:29:33 -0700 (PDT) Received: from [10.57.77.222] (unknown [10.57.77.222]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C12E03F762; Wed, 17 Jul 2024 01:29:06 -0700 (PDT) Message-ID: Date: Wed, 17 Jul 2024 09:29:05 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 2/2] mm: mTHP stats for pagecache folio allocations Content-Language: en-GB To: David Hildenbrand , Lance Yang , Baolin Wang Cc: Andrew Morton , Hugh Dickins , Jonathan Corbet , "Matthew Wilcox (Oracle)" , Barry Song , linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <20240711072929.3590000-1-ryan.roberts@arm.com> <20240711072929.3590000-3-ryan.roberts@arm.com> <9e0d84e5-2319-4425-9760-2c6bb23fc390@linux.alibaba.com> <756c359e-bb8f-481e-a33f-163c729afa31@redhat.com> <8c32a2fc-252d-406b-9fec-ce5bab0829df@arm.com> <5c58d9ea-8490-4ae6-b7bf-be816dab3356@redhat.com> <9052f430-2c5a-4d9d-b54c-bd093b797702@redhat.com> From: Ryan Roberts In-Reply-To: <9052f430-2c5a-4d9d-b54c-bd093b797702@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 412C580022 X-Stat-Signature: izddpixdzcnj7nmwkrd3ufjn61auhxbb X-Rspam-User: X-HE-Tag: 1721204949-240375 X-HE-Meta: U2FsdGVkX18/TEC0KSO4nsClhuiFOISvhRIyPHhClq9uvdLd8hjs3XMk+11BrtRHrqHfLYia2ys4IUNvz8ic4Q+zTFmIZtYiBw+fqhepUHQamPoSAWSkGkva6P/j99vbqgzQ1fRI0hhFsmJvvOOvDLKg67nH8BTWQtnVT4zOUL1FpYbJrSQw9IvESvTbBzQ2A+z49xjqnYkOSLH3AtUvyNzkxNQsaolaT4DrTUhhOGwX4UNc43B5pZIq7rqQlnuEr85P96xf65xbcTEyIex82EzjJOXp3nkPOjgq/30TSHfOQK2+b0TzRyapzWgMrckFy7Sb3icsbdlmXkLimSiLeKMQIq7P9doJvVfMc66W+pc0ON+66VRpzjIEoUjjUkvWh7EgkrOCxxdqbwy8/6+u9+VEKHp/OqpDV0XsdC7ZPwgz5hHD3jrWjzeoFozkSGMJeLPJMaheKwT9HwCxTNF92ff/cG8GVJtG7Nj61gnzr84hOmhqAmY0RbA+0Rsxme+2e7dHrNG4rjjJF3Dyk0hglgceMv5THTY4AEtI3tsgd5RippU+BbMYAC45KF9sYoFxZTYGsu93/uyf1JOT2AWXeSsCZmkrwPmPhq3/jj4x8QluUFVLh2eZd5iBbceBJe0nTB5Lp7ZgLfSwajWjP/kqXK2hzs7K24sS/ExcHO1Hauxlnwv9vEsYxmHMVqIkYzQLoOstVe9zRwriGK4IypSjFgIywaHZ7mmmwa5waDavnZD99Ihn8d/l7Ie0zw/GMutRUY7HUBgnKAYyxNGo6V1DsfZRFpbrk8krGUwmiy3UljBbQpTAzFERjbrKQaeMSw9PjGiQHbHE8PmoudC4EO0cA4IJFRY+SDh6TerAktkXIlYg8j0VrdZyJ0S0cjXnZ65IrTsDt8iD3XQFfPVcSkl/OSRJ/f+0/JpJyaFPpWKNa9HI86wsUH/5XaHnxdCE58KtYVtUq4kISFrBh+gNOHc lDY3QN5Y Bndt+qPgilXrDWl9UYvhODlxlj/suZtLV1MwnUKtqoPe9YgovP9akOhyR9f7oBkwL2DynJ941c9wgiUI6CoF7MhOKaOq8tNMkORr8jTbNkO61SfEgarNeDBFNuQRDlpP5O4FNwPnJDCsEbOEShvAxlEnQypWCcu6tBwuJLMGCtce5pxw= 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 17/07/2024 09:02, David Hildenbrand wrote: >>> Sorry, busy with other stuff. >>> >>> Indicating only what really exists sounds cleaner. But I wonder how we would >>> want to handle in general orders that are effectively non-existant? >> >> I'm not following your distinction between orders that don't "really exist" and >> orders that are "effectively non-existant". > > I'm questioning whether there should be a distinction at all. We should just > hide what is either non-existant (not implemented) or non-functional. Great we are on the same page. > >> >> I guess the real supported orders are: >> >>    anon: >>      min order: 2 >>      max order: PMD_ORDER >>    anon-shmem: >>      min order: 1 >>      max order: MAX_PAGECACHE_ORDER >>    tmpfs-shmem: >>      min order: PMD_ORDER <= 11 ? PMD_ORDER : NONE >>      max order: PMD_ORDER <= 11 ? PMD_ORDER : NONE >>    file: >>      min order: 1 >>      max order: MAX_PAGECACHE_ORDER > > That's my understanding. But not sure about anon-shmem really supporting > order-1, maybe we do. Oh, I thought we only had the restriction for anon folios now (due to deferred split queue), so assumed it would just work. With Gavin's THP_ORDERS_ALL_FILE_DEFAULT change, that certainly implies that shmem must support order-1. If it doesn't then we we might want to tidy that further. Baolin, perhaps you can confirm either way? > >> >> But today, controls and stats are exposed for: >> >>    anon: >>      min order: 2 >>      max order: PMD_ORDER >>    anon-shmem: >>      min order: 2 >>      max order: PMD_ORDER >>    tmpfs-shmem: >>      min order: PMD_ORDER >>      max order: PMD_ORDER >>    file: >>      min order: Nothing yet (this patch proposes 1) >>      max order: Nothing yet (this patch proposes MAX_PAGECACHE_ORDER) >> >> So I think there is definitely a bug for shmem where the minimum order control >> should be order-1 but its currently order-2. > > Maybe, did not play with that yet. Likely order-1 will work. (although probably > of questionable use :) ) You might have to expand on why its of "questionable use". I'd assume it has the same amount of value as using order-1 for regular page cache pages? i.e. half the number of objects to manage for the same amount of memory. > >> >> I also wonder about PUD-order for DAX? We don't currently have a stat/control. >> If we wanted to add it in future, if we take the "expose all stats/controls for >> all orders" approach, we would end up extending all the way to PUD-order and all >> the orders between PMD and PUD would be dummy for all memory types. That really >> starts to feel odd, so I still favour only populating what's really supported. > > I would go further and say that calling the fsdax thing a THP is borderline > wrong and we should not expose any new toggles for it that way. > > It really behaves much more like hugetlb folios that can be PTE-mapped ... we > cannot split these things, and they are not allocated from the buddy. So I > wouldn't worry about fsdax for now. > > fsdax support for compound pages (now large folios) probably never should have > been glued to any THP toggle. Yeah fair enough. I wasn't really arguing for adding any dax controls; I was just trying to think of examples as to why adding dummy controls might be a bad idea. > >> >> I propose to fix shmem (extend down to 1, stop at MAX_PAGECACHE_ORDER) and >> continue with the approach of "indicating only what really exists" for v2. >> >> Shout if you disagree. > > Makes sense. Excellent. I posted v2, which has these changes, yesterday afternoon. :)