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 D30A9C5AD49 for ; Tue, 3 Jun 2025 15:20:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6F8806B04A8; Tue, 3 Jun 2025 11:20:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6D02B6B04AA; Tue, 3 Jun 2025 11:20:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5E53C6B04AB; Tue, 3 Jun 2025 11:20:34 -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 352446B04A8 for ; Tue, 3 Jun 2025 11:20:34 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 96E74BE2A3 for ; Tue, 3 Jun 2025 15:20:33 +0000 (UTC) X-FDA: 83514451146.14.03DB252 Received: from mail-qt1-f180.google.com (mail-qt1-f180.google.com [209.85.160.180]) by imf22.hostedemail.com (Postfix) with ESMTP id AE1A0C000A for ; Tue, 3 Jun 2025 15:20:31 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=iGz3ItgN; spf=pass (imf22.hostedemail.com: domain of jyescas@google.com designates 209.85.160.180 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=1748964031; 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=78CV190tK21as27HQwEeJbZdS3UbWxafS0fOVgBTz30=; b=z3hM6Fmr3ryl8MqGyRGyilOurtcfw8RxNoTxo287HTdZxfZy9uqubapMGYs362n0l5wPTv OK01W5JgJwvN6i9r5RPHH3RXoSpNa9W4iQnJbGUbiA6wkECh6d3bpSElWuHpLYTgji6RkA nIGukzu+DYqot+uSxHQP8BhFFSmD+mQ= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=iGz3ItgN; spf=pass (imf22.hostedemail.com: domain of jyescas@google.com designates 209.85.160.180 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=1748964031; a=rsa-sha256; cv=none; b=6pwxkWRoMgpZ6KbniktZIofIndx1hDuQSKaxfcVYpJtDA72rGiVO1WN1vjgD7nGfWsoyv/ EKoHTEbeHR2LDXNiIhya8UL9DIvIjckYW4qo6WIeBOOlAkANrtms0FSsJSK26BViPXksn5 9WwSVrMKvEFB66q0sfOrNtCVpuxcZVI= Received: by mail-qt1-f180.google.com with SMTP id d75a77b69052e-47e9fea29easo460451cf.1 for ; Tue, 03 Jun 2025 08:20:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1748964031; x=1749568831; 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=78CV190tK21as27HQwEeJbZdS3UbWxafS0fOVgBTz30=; b=iGz3ItgNx83efTxbRiP8kVvCxcAZ32fh0HKe4wQxd7tHGOel4pNCVm6kDbWt/SgPMR BcWNIZ1kTPt+JyS7k7U146BpuHFSPWoiRGASRIjhbdnynhyg80JBIhR285Wn7VX7T2f1 lURPcQfwlWZ0KGrGw4E2dS/xiSO9KW4U20kVlz7ZDul7ZDC3Cqsseipwfx3seIMpvJoI wwoPeEkRrnPtN9pbpr23vrdr0nFn28/IsvlmOTfT/+TNlmIWnI/YF+GN0O3kh3lNzHKG JlNxiOzR7VOZF7VBTcad4OIIlOdVFlp3NoVEiPsV5mFP36B9RL6Ru+xPcjOr4pe9Cebh z6yA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748964031; x=1749568831; 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=78CV190tK21as27HQwEeJbZdS3UbWxafS0fOVgBTz30=; b=vLxtX7Xh/sYN7V1N5mTuTKhQ0MwaqvfqiEk87Xe2D+RFSd4KLmEQwjwFgZ2rm1yn8f EtZcQ06GskxxBr34kvoGTrom6TS+SDupfoQNFMRRo0im7rSYmCNp/x6pD+KN7AWp01nu gz+24m8b4M49LMpHmVQjRfL81hAz1HF0yCD5+omp9/YEIn6un+uzVgZ/7AgMdfqUsfBS vFoufKZEQjzgQFrM0ULM5UfeaLGVRmUf8iYkIimUeA/KOTtyNGtw2YXLVxXUp6sMvBUx cESCjsHtT6N0d86gkUcNdRYsP/YE2w/uOjG9wUzSJN0gnqbu7FVYn3rKQETLLhSu0ZQJ 4t4g== X-Forwarded-Encrypted: i=1; AJvYcCUn84UyegKHRY8DiZKTwFEVTBVKyAMT/wJe8cUdAtvFrfYRdYBc5qEKDypKb2CvAPW2JV0vg+8bxQ==@kvack.org X-Gm-Message-State: AOJu0YwKUA4eGLbOEMhU6wB74fy7tw8VOQ/9IjcpUNk1WPOYUZNoJ3LG YhWvmFudCqJIS1v7bFHNS9r6uWDyK2Sd/fB929UlpJPVZu7V2P0GK4A6QeJnscWmg22AiIX9AIF XO3QxU5O7C0LQADwutz8NGGHhp3dR0r48Wbf4QUqp X-Gm-Gg: ASbGnctfB9O58yX0hrGf4HQFnLV/MKHjkg0MBIcs5KoOjjHYVF18SaX5OJKrdizZo9f 9lYuSjiy/g4AFcgqNt9hY4KrSo015NZM9hIFfxVVz70NX4OYvbYocJ2k/X8n6B0l+edToJtCulc KVEr9FN/tQ1qg01zO1MZ6uSxxTHTLQJwBXJcq3Av1THPc3Bpja7tWjkc1Td6qJR2fxI2KfVkYdf Rl2DA== X-Google-Smtp-Source: AGHT+IEU2NWoKYw6uCt0aYXE5UKwpld70+yPiKC82maUxmd5SAPQO/hpqZHa8bNTdqgscuMj0WhGcvE3AIdEsV6fR08= X-Received: by 2002:ac8:6f17:0:b0:494:5797:ccad with SMTP id d75a77b69052e-4a59ae60a8bmr4187011cf.9.1748964030412; Tue, 03 Jun 2025 08:20:30 -0700 (PDT) MIME-Version: 1.0 References: <20250521215807.1860663-1-jyescas@google.com> <54943dbb-45fe-4b69-a6a8-96381304a268@redhat.com> In-Reply-To: <54943dbb-45fe-4b69-a6a8-96381304a268@redhat.com> From: Juan Yescas Date: Tue, 3 Jun 2025 08:20:18 -0700 X-Gm-Features: AX0GCFsk2ndzQ--DMsZEMW04cQTVWDjnNyZEio1KWux__YHKC7qFkD7N7-vV8vo Message-ID: Subject: Re: [PATCH v7] mm: Add CONFIG_PAGE_BLOCK_ORDER to select page block order To: David Hildenbrand Cc: Andrew Morton , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Zi Yan , linux-mm@kvack.org, linux-kernel@vger.kernel.org, tjmercier@google.com, isaacmanjarres@google.com, kaleshsingh@google.com, masahiroy@kernel.org, Minchan Kim Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: 8risj94dmxkou9tiypa7atghtuwbgphf X-Rspamd-Queue-Id: AE1A0C000A X-Rspamd-Server: rspam11 X-HE-Tag: 1748964031-908470 X-HE-Meta: U2FsdGVkX1/XsqpBf+xUBnlEj2ZMmE69FqMnY1lAA+IHXVtYsbwIfSU0p8nQD88Agc+fvQnjWmhNuONAkKMtHKluaQilwO6T052B4YLsSwjZYZ7otJdF1ZgpX0D60xHDHSjmoMhAXgU04eK42GVyn9Y5xY4uiJGmjcAZi8ZMitualcbzQD3WHI364Q28XC4P5R94jQnNr66K1YspcLiEzr2VYDvEA7qIvhxu4FxO2VMYNDTI9bnkRcd1CJlibwkGyA1XTPHoNOaj+vzpaq7lhJvRlf6szrXL0F51EYNDcf/OOXAgobrB7V0kfNlX7zN+ZCE7SSJryNopwQnSC3qFqWx4i5d7JFUZ6GR1sahngJKavwNB2khvcbDpf5dCqsvEqFibQrmuCvnldwpfTB6oy8WXXkgZ8EhRzGcKsArqk4a5xipw6VrVucB0TyVWrCwsrVzLz0EbevW+qp5bw8UmhiMujHPbN0dgmDj2pS3e0L4TJWimUnMynqs2bb9V3MzRsR8T8MiS6/vbP3eeRdVeDR9SSPV0nWWlmezfhsGoQpU67Fx/djipmYP9ZWFwUCSDR/sLUIVExtl6iGfvEPR1JEZOpPdT4UQ35F5W8fulMhRlkTuCa0uO/fV4q+7pb1JM6QJxZQ/5a9Z+WH6trSxOh37EMhzwTlVxmwXdwtpUfMUvtt89bu6c8tkMmGtQvTBx6hwoo+UEg94AsT8ctlYLgoyPqWPktsXw83wT1TCCYQAfgobBzHK6mXANaCCUoXBW5bT5oOG4Yb5GQ15+G57Lrdd/fdkk9Amko4S8EK3SrSlVI80INY5Nweh/ofE4sjzl3evk6KTht/wfqtnhjeaukqRLRj/vc1P9nYfIGaj7qSn9PZ03sqPtVt21rU+2KsU/vG/LBny8/u6MBv15g0EeZhQkrAjUqnjlN5+kxP1dCoc4afBDkvC2Z5ed2btJe0mUoWAij3PEtmdiJwiilgC Nis5FAw2 UU47NzZAk+ohUFN05caEw/v2vJ/6245PF4CdyGyjdfJ+OAfjI6xbra2SmDTxJGHqJw8BfcSXbOpaKc5A2dVb239dfhi7dYHjM4VKz8I0dc2NJA3GDWUmF6RbHACN05NnjOp9eluTOfBJT1/gSNTEVyqTWEk4q0tDPmusVKAB65+3nS8XhXUwUhGSfi4MQf4XkmR1so4o7YT6byTa2XaC9P4mQ8bnVESfRXFA040R6cX0ZqKH5Sgb6whXPFPwQw0Ao9vs4Ae05f/WMczRs8YdfIA6NMfHEg4LYsUQbJ5aVl4+kXT2mK7AKgSpRs2Myk3t0u1dntDXeJERqwp1qJUm/cuTLDReioFHvlHZf0HxUV1822SfGvHeDFsNcW/g8hDfplxcO/nk9kXnfWZVJLm98aq051DhHg2Cl3Hy5jhj8fpl73JuBcAGPr0S8a9DBI/JrMqPL3C/7XAdOuj8u8Y+6MBU1f3goEGhEXpOS+fD4y0cQjCR3sFgXBRVgwoo+9jnAgvh0zzcVYOWWVViAVk4KUyj1HNhqcPpnuixF 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 Tue, Jun 3, 2025 at 6:03=E2=80=AFAM David Hildenbrand = wrote: > > On 21.05.25 23:57, 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 | 9 | 4KiB * (2 ^ 9) =3D = 2MiB > > 16Kib | 11 | 11 | 16KiB * (2 ^ 11) =3D 3= 2MiB > > 64KiB | 13 | 13 | 64KiB * (2 ^ 13) =3D 51= 2MiB > > > > 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 12= 8MiB > > 16Kib | 13 | 13 | 16KiB * (2 ^ 13) =3D 12= 8MiB > > 64KiB | 13 | 13 | 64KiB * (2 ^ 13) =3D 51= 2MiB > > > > 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 */ > > ... > > }; > > }; > > > > 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. > > > > 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. > > > > 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 v7: > > - Update alignment calculation to 2MiB as per David's > > observation. > > - Update page block order calculation in mm/mm_init.c for > > powerpc when CONFIG_HUGETLB_PAGE_SIZE_VARIABLE is set. > > > > Changes in v6: > > - Applied the change provided by Zi Yan to fix > > the Kconfig. The change consists in evaluating > > to true or false in the if expression for range: > > range 1 if . > > > > Changes in v5: > > - Remove the ranges for CONFIG_PAGE_BLOCK_ORDER. The > > ranges with config definitions don't work in Kconfig, > > for example (range 1 MY_CONFIG). > > - Add PAGE_BLOCK_ORDER_MANUAL config for the > > page block order number. The default value was not > > defined. > > - Fix typos reported by Andrew. > > - Test default configs in powerpc. > > > > Changes in v4: > > - Set PAGE_BLOCK_ORDER in incluxe/linux/mmzone.h to > > validate that MAX_PAGE_ORDER >=3D PAGE_BLOCK_ORDER at > > compile time. > > - This change fixes the warning in: > > https://lore.kernel.org/oe-kbuild-all/202505091548.FuKO4b4v-lkp@in= tel.com/ > > > > 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/mmzone.h | 16 ++++++++++++++++ > > include/linux/pageblock-flags.h | 8 ++++---- > > mm/Kconfig | 34 ++++++++++++++++++++++++++++++++= + > > mm/mm_init.c | 2 +- > > 4 files changed, 55 insertions(+), 5 deletions(-) > > > > diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h > > index 6ccec1bf2896..05610337bbb6 100644 > > --- a/include/linux/mmzone.h > > +++ b/include/linux/mmzone.h > > @@ -37,6 +37,22 @@ > > > > #define NR_PAGE_ORDERS (MAX_PAGE_ORDER + 1) > > > > +/* Defines the order for the number of pages that have a migrate type.= */ > > +#ifndef CONFIG_PAGE_BLOCK_ORDER > > +#define PAGE_BLOCK_ORDER MAX_PAGE_ORDER > > +#else > > +#define PAGE_BLOCK_ORDER CONFIG_PAGE_BLOCK_ORDER > > +#endif /* CONFIG_PAGE_BLOCK_ORDER */ > > + > > +/* > > + * The MAX_PAGE_ORDER, which defines the max order of pages to be allo= cated > > + * by the buddy allocator, has to be larger or equal to the PAGE_BLOCK= _ORDER, > > + * which defines the order for the number of pages that can have a mig= rate type > > + */ > > +#if (PAGE_BLOCK_ORDER > MAX_PAGE_ORDER) > > +#error MAX_PAGE_ORDER must be >=3D PAGE_BLOCK_ORDER > > +#endif > > + > > /* > > * PAGE_ALLOC_COSTLY_ORDER is the order at which allocations are deem= ed > > * costly to service. That is between allocation orders which should > > diff --git a/include/linux/pageblock-flags.h b/include/linux/pageblock-= flags.h > > index fc6b9c87cb0a..e73a4292ef02 100644 > > --- a/include/linux/pageblock-flags.h > > +++ b/include/linux/pageblock-flags.h > > @@ -41,18 +41,18 @@ extern unsigned int pageblock_order; > > * Huge pages are a constant size, but don't exceed the maximum alloc= ation > > * 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 */ > > > > diff --git a/mm/Kconfig b/mm/Kconfig > > index e113f713b493..13a5c4f6e6b6 100644 > > --- a/mm/Kconfig > > +++ b/mm/Kconfig > > @@ -989,6 +989,40 @@ 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 > > + > > +# > > +# When ARCH_FORCE_MAX_ORDER is not defined, > > +# the default page block order is MAX_PAGE_ORDER (10) as per > > +# include/linux/mmzone.h. > > +# > > +config PAGE_BLOCK_ORDER > > + int "Page Block Order" > > + range 1 10 if ARCH_FORCE_MAX_ORDER =3D 0 > > + default 10 if ARCH_FORCE_MAX_ORDER =3D 0 > > + range 1 ARCH_FORCE_MAX_ORDER if ARCH_FORCE_MAX_ORDER !=3D 0 > > + default ARCH_FORCE_MAX_ORDER if ARCH_FORCE_MAX_ORDER !=3D 0 > > + 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. > > + > > + This config allows overriding the default page block order when= the > > + page block order is required to be smaller than ARCH_FORCE_MAX_= ORDER > > + or MAX_PAGE_ORDER. > > + > > + Reducing pageblock order can negatively impact THP generation > > + success rate. If your workloads uses THP heavily, please use th= is > > + option with caution. > > + > > + Don't change if unsure. > > > The semantics are now very confusing [1]. The default in x86-64 will be > 10, so we'll have > > CONFIG_PAGE_BLOCK_ORDER=3D10 > > > But then, we'll do this > > #define pageblock_order MIN_T(unsigned int, HPAGE_PMD_ORDER, > PAGE_BLOCK_ORDER) > > > So the actual pageblock order will be different than > CONFIG_PAGE_BLOCK_ORDER. > > Confusing. I agree that it becomes confusing due that pageblock_order value depends on whether THP, HugeTLB are set or not. > > Either CONFIG_PAGE_BLOCK_ORDER is misnamed (CONFIG_PAGE_BLOCK_ORDER_CEIL > ? CONFIG_PAGE_BLOCK_ORDER_LIMIT ?), or the semantics should be changed. > We could rename the configuration to CONFIG_PAGE_BLOCK_ORDER_CEIL. > [1] https://gitlab.com/cki-project/kernel-ark/-/merge_requests/3928 > > -- > Cheers, > > David / dhildenb >