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 CA1AAC77B6E for ; Fri, 14 Apr 2023 16:18:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 168D6900002; Fri, 14 Apr 2023 12:18:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1199A6B0075; Fri, 14 Apr 2023 12:18:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F2289900002; Fri, 14 Apr 2023 12:18:37 -0400 (EDT) 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 E307E6B0072 for ; Fri, 14 Apr 2023 12:18:37 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id A34A41A03AD for ; Fri, 14 Apr 2023 16:18:37 +0000 (UTC) X-FDA: 80680504674.25.D5FACB2 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf24.hostedemail.com (Postfix) with ESMTP id A6517180016 for ; Fri, 14 Apr 2023 16:18:34 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="L/oBdelF"; spf=none (imf24.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681489115; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=cS5oE4dq4L/8Z8t22e00OPv5vVVPGtUAiz+LjEIScJM=; b=XBqvHxyLcwUES7VP/sMVQkYfTLOvcNiL12GZ8IhVIVNejKGXXEWEy5wanWALw2z5N7eYKK cueDiqLyyuoNb5TgjhFp6eX29F+0EZ639V3RRIipurEFJ22PLyJ0VhJz6K64ZiQsHNyJIW +T9kmqGPTg/SjR8qRuhpw0rK+aGfIa0= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="L/oBdelF"; spf=none (imf24.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681489115; a=rsa-sha256; cv=none; b=4YXMJdv7puuCQcT0aeRgz5IWGjaj66LLS8u4rh934vUazGP9860GmJjSgw4AXTp0lq9XC3 xFBf9NkPjyNNnNBSG3ZRL3if0xtS81OY161c368OHJ+1+W7pSN5l1Pp2WJADLoWpOo/hql 03A2cEh8JW8ygjcNhSEhGM8ZU8zAqgI= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=cS5oE4dq4L/8Z8t22e00OPv5vVVPGtUAiz+LjEIScJM=; b=L/oBdelFwWGqRqIciG5bBJU2bk BuILNnTz3tnV7lWCt3PddrtFl2OWXo9on31dgmcv05KlbqMMhr1OCQRDFH1bKicogmWZ7/56p2AVU 0kU2BINDMtQNYuEgM50x2iDIDXHEMjsvWpEh2DeTAWuZceJUdm2R2iVRV0Xj8nT38NFKH2oRnBi7G ZBlNQJ4k2ZXtMHrVlMsU+TtzyiOujQ8WSWyDYo06GkIeUOdxh3QJb3PpfgRK3OCaMhQfOfJrRolPU qM0oVo+k9d9lM50OOdcKU3/Pf6icuKm9tSDQi8JklrABYAp4Gwkg27me76tQG/7Af5HBV+X1rYWFJ sl1sOLuA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pnM82-008t4M-Eu; Fri, 14 Apr 2023 16:18:26 +0000 Date: Fri, 14 Apr 2023 17:18:26 +0100 From: Matthew Wilcox To: Ryan Roberts Cc: "Kirill A. Shutemov" , Andrew Morton , Yu Zhao , "Yin, Fengwei" , linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org Subject: Re: [RFC v2 PATCH 05/17] mm: Routines to determine max anon folio allocation order Message-ID: References: <20230414130303.2345383-1-ryan.roberts@arm.com> <20230414130303.2345383-6-ryan.roberts@arm.com> <20230414140948.7pcaz6niyr2tpa7s@box.shutemov.name> <2b76ee7e-06d1-94ca-d22e-46b6302b7c30@arm.com> <20230414153747.n5kyhvb5a726lvrz@box.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: A6517180016 X-Stat-Signature: fcfz94eiuqtzo3f6xfsk5x94pjzbpeq7 X-HE-Tag: 1681489114-878928 X-HE-Meta: U2FsdGVkX19YIzMjsjfC2JbioIzC8qjdIormC7GQgComWYsOCD5fbH9ceVTuF9BLKQjtJPB9EeYrzPXzbYeoIqlaGg1RLhMjTp6iPG2bEolgfAus3/HSHkE2Szw45zpXFf4QsUsGcterKstv52Omu2JqGSldtc5ogE+vTGzzmHba0sqlp7pZllZEvTCPxZU3Iv9/Dd6EC32/vNMN7PXjiB8aYADPIx692cW4KRpFwsORtilCBr3Euyc9rdRIPNgcjS/iVunyMuVr5BiyPiHCBW7w5ZZRf0Cy2XWvVMH4nkAuH4LTmZ0pIY7UXgy09sGp3d4YcdIwUdhD8/YsdDgesuBq6Mxngpdmrg6x8aNDCBUn5rQRmrsUKyuP345s3ahTZO5DvU+or4Jqdr187xBb04JVUXaKDjOsHgyJ8aPi0TuQp9sS/d/+hPXx04Lu/u5HpzmUibD5m679e3gd3eibWNkDLJUbW0oaihhEW/iuhM2TjHao6CbwZnh39amTg73fObVj4ublTyRMkdQvQmotXQJ9Qt71ldxF9pd113FzEwnH6Ktq7G7ZxwF37E2E3x1GGf+GSWdKHBc7SjPq8MhPzbwzLXWf0bL+H52Clf7VdnCnfep4hL88BlRQDtA6j28v2kQ5eFbJAdPvc7x8rmsDapU5SVUzXeklU6I0zOAFIgYFn1t3J2BWieohA8mu/EQuVSOE+KP86qXedxcMx5myNFOpydOFWPUvUJ2Cid3vM59vxiONkt86QWUyxz46jPLfOs54yFaQXtaJsAS6HC1U20yG3OXv1gJjCq4Uxtrvv1ZcyW1XsAWJKXCv+V+rFqVfKHP6rzz0sCMRoC4wQfBIL0qOis6SREzXxJSrG6AMoSSjETaYIMR3p0bQKgU+RDplAygClsLgDsSenWkLnqH3Qzxwqy2ytCuV0/L61pbt0xvbm7mhcugPy2N8Ay3J6dPuffmkQ14XFmvn7oqB9Qo jcoIXy+J R7qcUfqQbXHYuYE3yP90FR1yqVDPUuuLs32FnhKxu0TltylsT8lWv0vYj65Itw+Ws0rusm9ePUsSWm6A5nqlsiLQFdf3u+tD6XEKzELPjnZFVeQStfajgxGDyl6AO8CE9o0KNx+2kD65kvz9xUeMYNIG88g== 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: On Fri, Apr 14, 2023 at 05:06:49PM +0100, Ryan Roberts wrote: > The point I'm thinking about is for 4K pages, we need to allocate 64K blocks to > use the contig bit. Roughly I guess that means going from average of 2K wastage > per anon VMA to 32K. Perhaps you can get away with that for a decent perf uplift. > > But for 64K pages, we need to allocate 2M blocks to use the contig bit. So that > takes average wastage from 32K to 1M. That feels a bit harder to justify. > Perhaps here, we should make a decision based on MADV_HUGEPAGE? > > So perhaps we actually want 2 values: one for if MADV_HUGEPAGE is not set on the > VMA, and one if it is? (with 64K pages I'm guessing there are many cases where > we won't PMD-map THPs - its 512MB). I'm kind of hoping that all this work takes away the benefit from CONFIG_PAGE_SIZE_64K, and we can just use 4k pages everywhere.