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 A0F32C3DA42 for ; Wed, 17 Jul 2024 10:18:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3C6176B0098; Wed, 17 Jul 2024 06:18:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3756A6B009A; Wed, 17 Jul 2024 06:18:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 264086B009C; Wed, 17 Jul 2024 06:18:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 09B026B0098 for ; Wed, 17 Jul 2024 06:18:15 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 76EED1A0A52 for ; Wed, 17 Jul 2024 10:18:14 +0000 (UTC) X-FDA: 82348844508.15.24257FD Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf12.hostedemail.com (Postfix) with ESMTP id AD6324001F for ; Wed, 17 Jul 2024 10:18:12 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=none; spf=pass (imf12.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=1721211462; 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=Mz900Rd5vAmeeLMQFeRcXQVzE3BUHSkUMzt6PZVhTgY=; b=qhLy4FteaInZ+PnXX3Vyegkj+tFOTbbnWljpp+/HqVgvgtJOoVERUmpZT3x7XkSeWn/17a Kg0SVddMbEh7M213bpC4+gQO958d+1zBhgdIvau5x/Eu+1AVymm9cjkHDOtgDxFsWufF2z 02JCnEExvj9xov6lZho1JchN0B7Ld9k= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=none; spf=pass (imf12.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=1721211462; a=rsa-sha256; cv=none; b=ESU5n9ufQk2eLvefyTLMom56cGweq8RjAK7Ul3NnfzD3hTLSQqFOxE/NM/EKuuUK1lpf92 kI6rg5hySN/Tf2zR/tNWdej7F9ZqQxMwZoYiAxVn8AJC2QZmzbVxa2bArdW4hd/F4889pE p1XKQ29WGgcS+8b+jXSIyWivXCZQzR0= 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 1DAE21063; Wed, 17 Jul 2024 03:18:37 -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 2BAC43F73F; Wed, 17 Jul 2024 03:18:10 -0700 (PDT) Message-ID: <41831175-6ea4-4e0b-8588-e51e5ee87f19@arm.com> Date: Wed, 17 Jul 2024 11:18:08 +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> <5472faf5-1fbe-4a89-a17e-83716fc00b5a@redhat.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Stat-Signature: 6gzgzuj9k6hwymc4rswb4zamtngfo7h9 X-Rspam-User: X-Rspamd-Queue-Id: AD6324001F X-Rspamd-Server: rspam02 X-HE-Tag: 1721211492-928991 X-HE-Meta: U2FsdGVkX1+73xxy46figySJmzB9vodz7PZCcdm81VCnOsW5FuYhcF8RedrKm7Ss7JNbVagNE9XJAtc+kDIGzba0dk8+WvV1lpBUa5WuYt774Xycmzjr280sXZM+S02Y2a1o9LEE/GL/IuKPKru27z1qjTmSGKm6yeNKMuilyTeun4a7bjBAWG4hL/D8vGZwft7avJ5WSjy6xZ0E+kmRZ35DjwTaYqTDW2fATH74XTU2n/n/1sMYsjnvOCleUhw+s+KZIeodlEkW6QIStMULDgRm/RJdDehuCdS/WLS9w/cG5ecZy+Nbj4lIQGJIySepEysEtSua+3V08s8ikW8mEj4XmWy0TVvD/q1d8CUoxPshUa+Kwwhi3HLg8MUSVNmD4YNThGGEFCnaPLG/qgJiEz0dXhU93KpmqXi8h9+0+4yxehdRQ7JqtAU7RQDptU32qsneFTpyIAelQGaFDO0admTiPorPKsRsYh7zRvmvQoqQ7Hg/pXW+W2oVvC+9CHiUUO0KukIPY9jDub+q5dz7wXDdjw15BBIwhh8hrbDsOfNZeSANmKdJOY7uufu16UYGKpb2yMBOzZDyQ2ZiNzubjWtPGEZN2evGg1d8QKbcb5QkVMhK/xiJMUYs8XnIgAvMiMsTiq06r4gAc5u6RvYjUKq/3NldCC9kUmSwqsVv0aVygGtCQTWXshZSGauudzucytduSGBNr1e9v08F0NKaTMAugqQBsPi7JCjfw/FP4LLQhufYPQMMySxszi26eDxn+OPLib1KnD3Um4BwDUKU72pDhqbILVTPHloritUDn5X3re1clJt7Lz44HyHl0IrsnVTOhTkZ5pOvX+anOMufmOkv7fBf5CG9H3Kf0RKraZqWbro0/d7vf8GOYLTxhXAKINIbHisKuL9JXGwG0at4dfbNQZMqsdlJG6XVjA3lKuI3r5c3MopAY9GQuwdtx0ACMfqh92L6t1TSEXHZ70G Fhpqonqw 34UCH9+eXqeb7o952Yu2xhPfqfpyQ52lndONloMEglRFTtIhHwPkf78kwQugTzUbkjc39swiJmW4yVX+asfz5BFF3HUZqFA/POYkcTkXveZ5k67A5PhRYmP8lPxCpS78qt+Ov8yPz+ZLHyAvbasXSN8/7Ek3bV2Mz8PzxtHQY4UxH8jQ= 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 11:03, David Hildenbrand wrote: >>>>>> >>>>>> 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. >>> >>> order-1 was recently added for the pagecache to get some device setups running >>> (IIRC, where we cannot use order-0, because device blocksize > PAGE_SIZE). >>> >>> You might be right about "half the number of objects", but likely just going for >>> order-2, order-3, order-4 ... for shmem might be even better. And simply falling >>> back to order-0 when you cannot get the larger orders. >> >> Sure, but then you're into the territory of baking in policy. Remember that >> originally I was only interested in 64K but the concensus was to expose all the >> sizes. Same argument applies to 8K; expose it and let others decide policy. > > I don't disagree. The point I'm trying to make is that there was so far there > was no strong evidence that it is really required. Support for the pagecache had > a different motivation for these special devices. Sure, but there was no clear need for anon mTHP orders other than order-2 and order-4 (for arm64's HPA and contpte, respectively), but we still chose to expose all the others. > > But again, I agree that we should just make it consistent and allow for it. :) Yes, we both agree, so I'll stop arguing now :) Thanks, as always, for the discussion!