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 3491CC3ABAC for ; Tue, 6 May 2025 16:08:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9734B6B0082; Tue, 6 May 2025 12:08:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 94AAA6B0085; Tue, 6 May 2025 12:08:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7C0DB6B0088; Tue, 6 May 2025 12:08:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 5AB3B6B0082 for ; Tue, 6 May 2025 12:08:31 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 103301405B4 for ; Tue, 6 May 2025 16:08:33 +0000 (UTC) X-FDA: 83412965706.25.DA78B67 Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.171]) by imf16.hostedemail.com (Postfix) with ESMTP id 178EC180011 for ; Tue, 6 May 2025 16:08:30 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=yam3FQFm; spf=pass (imf16.hostedemail.com: domain of jyescas@google.com designates 209.85.160.171 as permitted sender) smtp.mailfrom=jyescas@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1746547711; 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:dkim-signature; bh=xWJ9zoUWlBUqE0sXfkCqGQm7u6SmJH3pxd7Z4uT65pU=; b=yvearBkJr3AkqPEJ/ZW4WDcu9tXctQeeruk7oN07jnQpk+DltPr34zFvCvWdpscpE431k5 ac9j5T8+INo6GPoJkzI+22Cinyy9tjkzTKYjVu/Yz2eTrCeKcG7vUjwaD+TyR/tZWrSmy7 /K/36DAn4Lb2bMpvh/fxLl0wbDunC4A= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=yam3FQFm; spf=pass (imf16.hostedemail.com: domain of jyescas@google.com designates 209.85.160.171 as permitted sender) smtp.mailfrom=jyescas@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746547711; a=rsa-sha256; cv=none; b=QQrGaNV6COl1pC40RRojAsP7TpBfr/L+DqARTA2X9s7V0kjSKzNnfeKs0DjjJvqCgv/JpX bADFF3Yg5HD4nR0biRCS/WdWhyPmidYwKshP2uWHITPpRosoZjybpgS5xc7QY9R02KcVLd jHyZucHU3UqiJUPHWoKqzUddB4d4xlo= Received: by mail-qt1-f171.google.com with SMTP id d75a77b69052e-48b7747f881so314961cf.1 for ; Tue, 06 May 2025 09:08:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1746547710; x=1747152510; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=xWJ9zoUWlBUqE0sXfkCqGQm7u6SmJH3pxd7Z4uT65pU=; b=yam3FQFmnCFLn8ul0Cane+jyDrqbLp21w0v0mvMvEvQC26Gf9mSrHjtC47A837E86M 6kZrdx4NPyoEtG/dd8k+ZOlDhtmJjVSDB+7vpwZTuBXqMVOsbqdiCKwc3n8IUe0yT8Ff l97+dlARmb2XSlTa3khT+nnG2emraX/mFFa0uFjORYQE32oRGsDC0k06BQXI2/fYpfhH RRa5V4WHMsWlZFkPyedFiH10eb2G6al01CLqmWhRgBakB45/b4g3PnmK8PYoLlORIMb4 RSNT/quRzc+5wQzdc3yAijMIJwugWnpvonLmphRSoEf7G8AniOsMRE/kdlSgezSCHo3d VpIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746547710; x=1747152510; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=xWJ9zoUWlBUqE0sXfkCqGQm7u6SmJH3pxd7Z4uT65pU=; b=pvjCjCo370C82LBqZbz7Xi8fGySLd9w0NeyjfHGdMFRZO4a+aIKaYEGy2OY6S24jyu tuASFzdBpvukqqEYY2EwnKgt9gHe+b8Dfw4Wge18nx2R1CU0jxiX5dAfK+KnE5EIv4bm /tNhVWpMQgSlCpBjeWE3LydWLJjDrR2OqDnyQnIRqzA+EVdsCSnFeOAnHxbzjJA0ZMPF 7zkvycwh/cNK5hpCrRdb/p0N5G+wpAWqadqDjbuLUCqCowRy5YzRlGOPJpnbZrurxxRb LMGOwFQVmHq97s83lI0MhrogTgMbOn2w4ai53U+ZJvDGBBIlKZ2cLIipMLVvxkbDzZTe n0tA== X-Forwarded-Encrypted: i=1; AJvYcCWrwBLrNwdz3nuvCD63mtK6+maA9dN36KuNBy/fWRdLOScb61fKw1/pTmSHpOO/8xBnrEUol7C8pQ==@kvack.org X-Gm-Message-State: AOJu0YxvR8YHOhT/Q1QEd5UZoo7AiqHuyIBC/ORXwL+i7IgC2Ge2M5Ds yDtpF5ZmHH02mdwK96ijwwr7+RVXYdmGQA+vc8rfNWs7/iYSVKre2I2Q70ewOWbs7fCe0ioQFK1 /TSeh5mIOcK+5dOHGc5sdwx7fUhlXqP6co28t X-Gm-Gg: ASbGncsuZ1LBoHFQQq6O4jWjF295d3KoE24VTECM7dy1zemObwdF7jrth4dv1DFA7DN 6rnsqvdJY8IMsu9/I4PTyWtt6lmrpqGPibiz0fmLNw5RzUaMGVfkr2zbgNKvJbOr9ukjfim/UtH 0F8azOl4vwaZDpIiHQVj2sl7dYUAp8ABYR4lk9Epqboq9fZzDfkyjT7qg= X-Google-Smtp-Source: AGHT+IE9HQStKmdCVvuXN8pwokAeyXR9wvitUGA+/pdKZfFusSEcNLLWW6B0rJPJ7BYVhidXD0ZJv0veYGKl1qSxu6c= X-Received: by 2002:a05:622a:2d2:b0:477:8686:901d with SMTP id d75a77b69052e-491ff65fbeamr446051cf.1.1746547709667; Tue, 06 May 2025 09:08:29 -0700 (PDT) MIME-Version: 1.0 References: <20250506002319.513795-1-jyescas@google.com> <64a0c678-ead9-4620-b69b-e631d6e540f9@arm.com> In-Reply-To: <64a0c678-ead9-4620-b69b-e631d6e540f9@arm.com> From: Juan Yescas Date: Tue, 6 May 2025 09:08:17 -0700 X-Gm-Features: ATxdqUEwGUN7QDvI02zIl2FoaXEI0NoL7oCbzfgxmcbq_TL4RqObWLAXRIFXArQ Message-ID: Subject: Re: [PATCH v3] mm: Add CONFIG_PAGE_BLOCK_ORDER to select page block order To: Anshuman Khandual Cc: Andrew Morton , Zi Yan , linux-mm@kvack.org, linux-kernel@vger.kernel.org, tjmercier@google.com, isaacmanjarres@google.com, surenb@google.com, kaleshsingh@google.com, Vlastimil Babka , "Liam R. Howlett" , Lorenzo Stoakes , David Hildenbrand , Mike Rapoport , Minchan Kim Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: cmgzeh7mqgep5oiqk9auta4ausmokxte X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 178EC180011 X-Rspam-User: X-HE-Tag: 1746547710-592049 X-HE-Meta: U2FsdGVkX1/HLCJvinCNGuGNwz8Qcr1GtGBVqj3epnQJeg2ktcVw+1Ob25bcJ++kwMJS7B2K2AVFsInF5fXBSm6808KEVsZfI2Npq9F73uVaTu7qARGkOjOLREEkzRhs9yaCZ/pxDpcuw8SgI/pPn8sGrWNfwD9W/EDNuSSfUUDWWk61nyUIJJAhQlx59A5M0cw1eUYgMed9wf5GHgw2ALQGij0xLmeT4m5BDFsFXghN1JPldhc8LSAlKoBvXB0jL3yRDV/1kTHQnmr9nPw0DsoPA2duRcfbhur8AcudqvaiiY7c4ALZD5CVh9YN1YxfOl1vSqBrhWhKIa6Fywx7WwRe86Vk5qO4E5PkakatZ+yyLXkvmpb9ITwP5h5XCMYuRppJKthBfK+Gidhf03fEtB5iqq09cPQSwLWo5JsfopunQU2EzIBrrm+eXBc3v+UAB23XCWErdQyjMk+EzIWKIxf06Kg9fq+5vjf74htdBvWAHCrR/83t/2GE8IDOVSrkFJqBWxRDNwmk2AwRfwxptuKV+g6navmB3oONPdpH+9iOK87m/gwJ6AaIaklRX565x9xqvLlgymVe1qsyg4S9FcgIy5lD4UG72Dm4g4LhtGVjEJ1EZkcs06NI2JHLoTmJoaguLZs2gqea+7rnVqONOjy9tFm12h1o2tySEOt1rtOh1rk7qkvpVcxyewtEU0wvcbnLQODbgqmKBlWsfPBal7tiVxKh+RM5GMWjW4DA0ohSSErl1+ECrtYb7tiwp5yx5cOY5RAUimMr12Jn0nnWrmo0SPr7Diqcl48LNwnDR6Waj+o5A/Xz5uYkalkQXnvhzalYxn7incNC2h2bJEiIQHCfDFGGo/XeSw6MsoSqub+6kfi/j5vEu0Hoxh59AtGsirtqh8bgpyXLkBDjCEvXfU/1A0FQ66zD9y7WDSPppW++mG7N0qlFKrSZZvkSnnqfIeyh+Bt5efk1Za3Eeid mdrdUr5z ndF7pg/ymFqZ9FQgGzhsPYjd/w995fl581vgVTBgtmSREeRGMeVA/MgwncReN4oXx+/EZUaujZFMFdmkhW4LAoYKCPWhQQJSmE8qJBL/o5HDDT95vMSgJdAsLnnhZazeRxRm+PJpnOKWPQmua8HkVRocjHR90X3jx9go9aSnVjOK4bSTm5+5Vsykbk8QkOzCAvrCCn+QDCH2XesveB9g7I1moLXTiP265ROCEVrEnBp+i4HMXT6KjxP3zVdoMntYmr94I7zg0oQIjN1ITFncqIZf17kg1CQDkrhDV1wAvGc++6Yqiih6+y6GROHl4ORYeX9/+aRJ0rqCBRc//ksJm5338PF20JhGEqTzsBttJz0Dv89gTX649h11wMQURmKuQRefMxeo/QfxQPPojYDZL/qCfN+Vb2m11NiGgzZun74GxaNYmgb87eBx9tf28sNxYCWIdyqIYdglorZJM4INlCgjCMOHlbKKhPJdgPVgCe3uNSmD87PBfIdxzbEBQrjjPBOUcyDaYZLXHuCbCnqpMR4W+flMMzYQPBHgVnMEMkYgXnqC5PWt6Db8r2/G/xz/tHKTCWYrPzspYDDeYMYyYgOo+/Ae1uQZU1XaRk8Gs9Hm83oM= 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 Mon, May 5, 2025 at 11:53=E2=80=AFPM Anshuman Khandual wrote: > > On 5/6/25 05:52, Juan Yescas wrote: > > Problem: On large page size configurations (16KiB, 64KiB), the CMA > > alignment requirement (CMA_MIN_ALIGNMENT_BYTES) increases considerably, > > and this causes the CMA reservations to be larger than necessary. > > This means that system will have less available MIGRATE_UNMOVABLE and > > MIGRATE_RECLAIMABLE page blocks since MIGRATE_CMA can't fallback to the= m. > > > > The CMA_MIN_ALIGNMENT_BYTES increases because it depends on > > MAX_PAGE_ORDER which depends on ARCH_FORCE_MAX_ORDER. The value of > > ARCH_FORCE_MAX_ORDER increases on 16k and 64k kernels. > > > > For example, in ARM, the CMA alignment requirement when: > > > > - CONFIG_ARCH_FORCE_MAX_ORDER default value is used > > - CONFIG_TRANSPARENT_HUGEPAGE is set: > > > > PAGE_SIZE | MAX_PAGE_ORDER | pageblock_order | CMA_MIN_ALIGNMENT_BYTES > > ----------------------------------------------------------------------- > > 4KiB | 10 | 10 | 4KiB * (2 ^ 10) =3D 4= MiB > > 16Kib | 11 | 11 | 16KiB * (2 ^ 11) =3D 32= MiB > > 64KiB | 13 | 13 | 64KiB * (2 ^ 13) =3D 512= MiB > > > > There are some extreme cases for the CMA alignment requirement when: > > > > - CONFIG_ARCH_FORCE_MAX_ORDER maximum value is set > > - CONFIG_TRANSPARENT_HUGEPAGE is NOT set: > > - CONFIG_HUGETLB_PAGE is NOT set > > > > PAGE_SIZE | MAX_PAGE_ORDER | pageblock_order | CMA_MIN_ALIGNMENT_BYTES > > -----------------------------------------------------------------------= - > > 4KiB | 15 | 15 | 4KiB * (2 ^ 15) =3D 128= MiB > > 16Kib | 13 | 13 | 16KiB * (2 ^ 13) =3D 128= MiB > > 64KiB | 13 | 13 | 64KiB * (2 ^ 13) =3D 512= MiB > > > > This affects the CMA reservations for the drivers. If a driver in a > > 4KiB kernel needs 4MiB of CMA memory, in a 16KiB kernel, the minimal > > reservation has to be 32MiB due to the alignment requirements: > > > > reserved-memory { > > ... > > cma_test_reserve: cma_test_reserve { > > compatible =3D "shared-dma-pool"; > > size =3D <0x0 0x400000>; /* 4 MiB */ > > ... > > }; > > }; > > > > reserved-memory { > > ... > > cma_test_reserve: cma_test_reserve { > > compatible =3D "shared-dma-pool"; > > size =3D <0x0 0x2000000>; /* 32 MiB */ > > ... > > }; > > }; > > This indeed is a valid problem which reduces available memory for > non-CMA page blocks on system required for general memory usage. > > > > > Solution: Add a new config CONFIG_PAGE_BLOCK_ORDER that > > allows to set the page block order in all the architectures. > > The maximum page block order will be given by > > ARCH_FORCE_MAX_ORDER. > > > > By default, CONFIG_PAGE_BLOCK_ORDER will have the same > > value that ARCH_FORCE_MAX_ORDER. This will make sure that > > current kernel configurations won't be affected by this > > change. It is a opt-in change. > > Right. > > > > > This patch will allow to have the same CMA alignment > > requirements for large page sizes (16KiB, 64KiB) as that > > in 4kb kernels by setting a lower pageblock_order. > > > > Tests: > > > > - Verified that HugeTLB pages work when pageblock_order is 1, 7, 10 > > on 4k and 16k kernels. > > > > - Verified that Transparent Huge Pages work when pageblock_order > > is 1, 7, 10 on 4k and 16k kernels. > > > > - Verified that dma-buf heaps allocations work when pageblock_order > > is 1, 7, 10 on 4k and 16k kernels. > > pageblock_order are choosen as 1, 7 and 10 to cover the entire possible > range for ARCH_FORCE_MAX_ORDER. Although kernel CI should test this for > all values in the range. Because this now opens up different ranges for > different platforms which were never tested earlier. > > > > > Benchmarks: > > > > The benchmarks compare 16kb kernels with pageblock_order 10 and 7. The > > reason for the pageblock_order 7 is because this value makes the min > > CMA alignment requirement the same as that in 4kb kernels (2MB). > > > > - Perform 100K dma-buf heaps (/dev/dma_heap/system) allocations of > > SZ_8M, SZ_4M, SZ_2M, SZ_1M, SZ_64, SZ_8, SZ_4. Use simpleperf > > (https://developer.android.com/ndk/guides/simpleperf) to measure > > the # of instructions and page-faults on 16k kernels. > > The benchmark was executed 10 times. The averages are below: > > > > # instructions | #page-faults > > order 10 | order 7 | order 10 | order 7 > > -------------------------------------------------------- > > 13,891,765,770 | 11,425,777,314 | 220 | 217 > > 14,456,293,487 | 12,660,819,302 | 224 | 219 > > 13,924,261,018 | 13,243,970,736 | 217 | 221 > > 13,910,886,504 | 13,845,519,630 | 217 | 221 > > 14,388,071,190 | 13,498,583,098 | 223 | 224 > > 13,656,442,167 | 12,915,831,681 | 216 | 218 > > 13,300,268,343 | 12,930,484,776 | 222 | 218 > > 13,625,470,223 | 14,234,092,777 | 219 | 218 > > 13,508,964,965 | 13,432,689,094 | 225 | 219 > > 13,368,950,667 | 13,683,587,37 | 219 | 225 > > ------------------------------------------------------------------- > > 13,803,137,433 | 13,131,974,268 | 220 | 220 Averages > > > > There were 4.85% #instructions when order was 7, in comparison > > with order 10. > > > > 13,803,137,433 - 13,131,974,268 =3D -671,163,166 (-4.86%) > > > > The number of page faults in order 7 and 10 were the same. > > > > These results didn't show any significant regression when the > > pageblock_order is set to 7 on 16kb kernels. > > > > - Run speedometer 3.1 (https://browserbench.org/Speedometer3.1/) 5 time= s > > on the 16k kernels with pageblock_order 7 and 10. > > > > order 10 | order 7 | order 7 - order 10 | (order 7 - order 10) % > > ------------------------------------------------------------------- > > 15.8 | 16.4 | 0.6 | 3.80% > > 16.4 | 16.2 | -0.2 | -1.22% > > 16.6 | 16.3 | -0.3 | -1.81% > > 16.8 | 16.3 | -0.5 | -2.98% > > 16.6 | 16.8 | 0.2 | 1.20% > > ------------------------------------------------------------------- > > 16.44 16.4 -0.04 -0.24% Averages > > > > The results didn't show any significant regression when the > > pageblock_order is set to 7 on 16kb kernels. > > > > Cc: Andrew Morton > > Cc: Vlastimil Babka > > Cc: Liam R. Howlett > > Cc: Lorenzo Stoakes > > Cc: David Hildenbrand > > CC: Mike Rapoport > > Cc: Zi Yan > > Cc: Suren Baghdasaryan > > Cc: Minchan Kim > > Signed-off-by: Juan Yescas > > Acked-by: Zi Yan > > --- > > Changes in v3: > > - Rename ARCH_FORCE_PAGE_BLOCK_ORDER to PAGE_BLOCK_ORDER > > as per Matthew's suggestion. > > - Update comments in pageblock-flags.h for pageblock_order > > value when THP or HugeTLB are not used. > > > > Changes in v2: > > - Add Zi's Acked-by tag. > > - Move ARCH_FORCE_PAGE_BLOCK_ORDER config to mm/Kconfig as > > per Zi and Matthew suggestion so it is available to > > all the architectures. > > - Set ARCH_FORCE_PAGE_BLOCK_ORDER to 10 by default when > > ARCH_FORCE_MAX_ORDER is not available. > > > > > > > > > > include/linux/pageblock-flags.h | 14 ++++++++++---- > > mm/Kconfig | 31 +++++++++++++++++++++++++++++++ > > 2 files changed, 41 insertions(+), 4 deletions(-) > > > > diff --git a/include/linux/pageblock-flags.h b/include/linux/pageblock-= flags.h > > index fc6b9c87cb0a..0c4963339f0b 100644 > > --- a/include/linux/pageblock-flags.h > > +++ b/include/linux/pageblock-flags.h > > @@ -28,6 +28,12 @@ enum pageblock_bits { > > NR_PAGEBLOCK_BITS > > }; > > > > +#if defined(CONFIG_PAGE_BLOCK_ORDER) > > +#define PAGE_BLOCK_ORDER CONFIG_PAGE_BLOCK_ORDER > > +#else > > +#define PAGE_BLOCK_ORDER MAX_PAGE_ORDER > > +#endif /* CONFIG_PAGE_BLOCK_ORDER */ > > + > > #if defined(CONFIG_HUGETLB_PAGE) > > > > #ifdef CONFIG_HUGETLB_PAGE_SIZE_VARIABLE > > @@ -41,18 +47,18 @@ extern unsigned int pageblock_order; > > * Huge pages are a constant size, but don't exceed the maximum alloca= tion > > * granularity. > > */ > > -#define pageblock_order MIN_T(unsigned int, HUGETLB_PAGE_= ORDER, MAX_PAGE_ORDER) > > +#define pageblock_order MIN_T(unsigned int, HUGETLB_PAGE_= ORDER, PAGE_BLOCK_ORDER) > > > > #endif /* CONFIG_HUGETLB_PAGE_SIZE_VARIABLE */ > > > > #elif defined(CONFIG_TRANSPARENT_HUGEPAGE) > > > > -#define pageblock_order MIN_T(unsigned int, HPAGE_PMD_ORD= ER, MAX_PAGE_ORDER) > > +#define pageblock_order MIN_T(unsigned int, HPAGE_PMD_ORD= ER, PAGE_BLOCK_ORDER) > > > > #else /* CONFIG_TRANSPARENT_HUGEPAGE */ > > > > -/* If huge pages are not used, group by MAX_ORDER_NR_PAGES */ > > -#define pageblock_order MAX_PAGE_ORDER > > +/* If huge pages are not used, group by PAGE_BLOCK_ORDER */ > > +#define pageblock_order PAGE_BLOCK_ORDER > > > > #endif /* CONFIG_HUGETLB_PAGE */ > > > > These all look good. > > > diff --git a/mm/Kconfig b/mm/Kconfig > > index e113f713b493..c52be3489aa3 100644 > > --- a/mm/Kconfig > > +++ b/mm/Kconfig > > @@ -989,6 +989,37 @@ config CMA_AREAS > > > > If unsure, leave the default value "8" in UMA and "20" in NUMA. > > > > +# > > +# Select this config option from the architecture Kconfig, if availabl= e, to set > > +# the max page order for physically contiguous allocations. > > +# > > +config ARCH_FORCE_MAX_ORDER > > + int > > ARCH_FORCE_MAX_ORDER needs to be defined here first before PAGE_BLOCK_ORD= ER > could use that subsequently.But ARCH_FORCE_MAX_ORDER is defined in variou= s > architectures in 'int' or 'int ""' formats. So could there b= e > a problem for this config to be defined both in generic and platform code= ? > But clearly ARCH_FORCE_MAX_ORDER still remains a arch specific config. > > #git grep "config ARCH_FORCE_MAX_ORDER" > arch/arc/Kconfig:config ARCH_FORCE_MAX_ORDER > arch/arm/Kconfig:config ARCH_FORCE_MAX_ORDER > arch/arm64/Kconfig:config ARCH_FORCE_MAX_ORDER > arch/loongarch/Kconfig:config ARCH_FORCE_MAX_ORDER > arch/m68k/Kconfig.cpu:config ARCH_FORCE_MAX_ORDER > arch/mips/Kconfig:config ARCH_FORCE_MAX_ORDER > arch/nios2/Kconfig:config ARCH_FORCE_MAX_ORDER > arch/powerpc/Kconfig:config ARCH_FORCE_MAX_ORDER > arch/sh/mm/Kconfig:config ARCH_FORCE_MAX_ORDER > arch/sparc/Kconfig:config ARCH_FORCE_MAX_ORDER > arch/xtensa/Kconfig:config ARCH_FORCE_MAX_ORDER > mm/Kconfig:config ARCH_FORCE_MAX_ORDER > > arch/arc/ > > config ARCH_FORCE_MAX_ORDER > int "Maximum zone order" > > arch/arm/ > > config ARCH_FORCE_MAX_ORDER > int "Order of maximal physically contiguous allocations" > > arch/arm64/ > > config ARCH_FORCE_MAX_ORDER > int > ........... > > arch/sparc/ > > config ARCH_FORCE_MAX_ORDER > int "Order of maximal physically contiguous allocations" > > > + > > +# When ARCH_FORCE_MAX_ORDER is not defined, the default page block ord= er is 10, > > Just wondering - why the default is 10 ? > When CONFIG_ARCH_FORCE_MAX_ORDER is not defined, the default is 10 for MAX_PAGE_ORDER in include/linux/mmzone.h. https://elixir.bootlin.com/linux/v6.15-rc5/source/include/linux/mmzone.h#L3= 0 My understanding is that with the default order 10 for MAX_PAGE_ORDER, we make sure that we can allocate huge pages using the buddy allocator when PAGE_SIZE =3D 4096. For example, we can allocate 2 huge pages of 2MiB using the buddy allocator: (2 ^ 10) * 4096 =3D 4194304 =3D 4 MiB Could any of the mm experts confirm this? > > +# as per include/linux/mmzone.h. > > +config PAGE_BLOCK_ORDER > > + int "Page Block Order" > > + range 1 10 if !ARCH_FORCE_MAX_ORDER > > Also why the range is restricted to 10 ? The PAGE_BLOCK_ORDER has to be less or equal to the MAX_PAGE_ORDER when ARCH_FORCE_MAX_ORDER is not defined. Thanks Juan > > > + default 10 if !ARCH_FORCE_MAX_ORDER > > + range 1 ARCH_FORCE_MAX_ORDER if ARCH_FORCE_MAX_ORDER > > + default ARCH_FORCE_MAX_ORDER if ARCH_FORCE_MAX_ORDER > > We still have the MAX_PAGE_ORDER which maps into ARCH_FORCE_MAX_ORDER > when available or otherwise just falls back as 10. > > /* Free memory management - zoned buddy allocator. */ > #ifndef CONFIG_ARCH_FORCE_MAX_ORDER > #define MAX_PAGE_ORDER 10 > #else > #define MAX_PAGE_ORDER CONFIG_ARCH_FORCE_MAX_ORDER > #endif > > Hence could PAGE_BLOCK_ORDER config description block be simplified as > > config PAGE_BLOCK_ORDER > int "Page Block Order" > range 1 MAX_PAGE_ORDER > default MAX_PAGE_ORDER > > As MAX_PAGE_ORDER could switch between ARCH_FORCE_MAX_ORDER and 10 as > and when required. > > > + > > + help > > + The page block order refers to the power of two number of pages= that > > + are physically contiguous and can have a migrate type associate= d to > > + them. The maximum size of the page block order is limited by > > + ARCH_FORCE_MAX_ORDER. > > s/ARCH_FORCE_MAX_ORDER/ARCH_FORCE_MAX_ORDER when available on the platfor= m/ ? > > Also mention about max range when ARCH_FORCE_MAX_ORDER is not available. > > > + > > + This option allows overriding the default setting when the page > > + block order requires to be smaller than ARCH_FORCE_MAX_ORDER. > > + > > + Reducing pageblock order can negatively impact THP generation > > + successful rate. If your workloads uses THP heavily, please use= this > > + option with caution. > > Just wondering - could there be any other side effects besides THP ? Will= it > be better to depend on CONFIG_EXPERT while selecting anything other than = the > default option i.e ARCH_FORCE_MAX_ORDER or 10 from the value range. > > > + > > + Don't change if unsure. > > + > > config MEM_SOFT_DIRTY > > bool "Track memory changes" > > depends on CHECKPOINT_RESTORE && HAVE_ARCH_SOFT_DIRTY && PROC_FS