include/linux/mmzone.h | 16 ++++++++++++++++ include/linux/pageblock-flags.h | 8 ++++---- mm/Kconfig | 31 +++++++++++++++++++++++++++++++ 3 files changed, 51 insertions(+), 4 deletions(-)
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 them.
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) = 4MiB
16Kib | 11 | 11 | 16KiB * (2 ^ 11) = 32MiB
64KiB | 13 | 13 | 64KiB * (2 ^ 13) = 512MiB
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) = 128MiB
16Kib | 13 | 13 | 16KiB * (2 ^ 13) = 128MiB
64KiB | 13 | 13 | 64KiB * (2 ^ 13) = 512MiB
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 = "shared-dma-pool";
size = <0x0 0x400000>; /* 4 MiB */
...
};
};
reserved-memory {
...
cma_test_reserve: cma_test_reserve {
compatible = "shared-dma-pool";
size = <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 = -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 times
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 <akpm@linux-foundation.org>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Liam R. Howlett <Liam.Howlett@oracle.com>
Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: David Hildenbrand <david@redhat.com>
CC: Mike Rapoport <rppt@kernel.org>
Cc: Zi Yan <ziy@nvidia.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Minchan Kim <minchan@kernel.org>
Signed-off-by: Juan Yescas <jyescas@google.com>
Acked-by: Zi Yan <ziy@nvidia.com>
---
Changes in v4:
- Set PAGE_BLOCK_ORDER in incluxe/linux/mmzone.h to
validate that MAX_PAGE_ORDER >= PAGE_BLOCK_ORDER at
compile time.
- This change fixes the warning in:
https://lore.kernel.org/oe-kbuild-all/202505091548.FuKO4b4v-lkp@intel.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 | 31 +++++++++++++++++++++++++++++++
3 files changed, 51 insertions(+), 4 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 allocated
+ * 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 migrate type
+ */
+#if (PAGE_BLOCK_ORDER > MAX_PAGE_ORDER)
+#error MAX_PAGE_ORDER must be >= PAGE_BLOCK_ORDER
+#endif
+
/*
* PAGE_ALLOC_COSTLY_ORDER is the order at which allocations are deemed
* 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 allocation
* 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_ORDER, MAX_PAGE_ORDER)
+#define pageblock_order MIN_T(unsigned int, HPAGE_PMD_ORDER, 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..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 available, 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 10,
+# as per include/linux/mmzone.h.
+config PAGE_BLOCK_ORDER
+ int "Page Block Order"
+ range 1 10 if !ARCH_FORCE_MAX_ORDER
+ 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
+
+ help
+ The page block order refers to the power of two number of pages that
+ are physically contiguous and can have a migrate type associated to
+ them. The maximum size of the page block order is limited by
+ ARCH_FORCE_MAX_ORDER.
+
+ 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.
+
+ Don't change if unsure.
+
config MEM_SOFT_DIRTY
bool "Track memory changes"
depends on CHECKPOINT_RESTORE && HAVE_ARCH_SOFT_DIRTY && PROC_FS
--
2.49.0.1015.ga840276032-googOn 9 May 2025, at 21:02, 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 them.
>
> 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) = 4MiB
> 16Kib | 11 | 11 | 16KiB * (2 ^ 11) = 32MiB
> 64KiB | 13 | 13 | 64KiB * (2 ^ 13) = 512MiB
>
> 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) = 128MiB
> 16Kib | 13 | 13 | 16KiB * (2 ^ 13) = 128MiB
> 64KiB | 13 | 13 | 64KiB * (2 ^ 13) = 512MiB
>
> 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 = "shared-dma-pool";
> size = <0x0 0x400000>; /* 4 MiB */
> ...
> };
> };
>
> reserved-memory {
> ...
> cma_test_reserve: cma_test_reserve {
> compatible = "shared-dma-pool";
> size = <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 = -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 times
> 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 <akpm@linux-foundation.org>
> Cc: Vlastimil Babka <vbabka@suse.cz>
> Cc: Liam R. Howlett <Liam.Howlett@oracle.com>
> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> Cc: David Hildenbrand <david@redhat.com>
> CC: Mike Rapoport <rppt@kernel.org>
> Cc: Zi Yan <ziy@nvidia.com>
> Cc: Suren Baghdasaryan <surenb@google.com>
> Cc: Minchan Kim <minchan@kernel.org>
> Signed-off-by: Juan Yescas <jyescas@google.com>
> Acked-by: Zi Yan <ziy@nvidia.com>
> ---
> Changes in v4:
> - Set PAGE_BLOCK_ORDER in incluxe/linux/mmzone.h to
> validate that MAX_PAGE_ORDER >= PAGE_BLOCK_ORDER at
> compile time.
> - This change fixes the warning in:
> https://lore.kernel.org/oe-kbuild-all/202505091548.FuKO4b4v-lkp@intel.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 | 31 +++++++++++++++++++++++++++++++
> 3 files changed, 51 insertions(+), 4 deletions(-)
Hi Juan,
The patch below on top of your v4 fixed powerpc build issue, as I tested
it locally.
From 5c2ae4dfca135e99da45302e4f5d96a315a99603 Mon Sep 17 00:00:00 2001
From: Zi Yan <ziy@nvidia.com>
Date: Sat, 17 May 2025 14:49:39 -0400
Subject: [PATCH] fix CONFIG_PAGE_BLOCK_ORDER
Signed-off-by: Zi Yan <ziy@nvidia.com>
---
mm/Kconfig | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/mm/Kconfig b/mm/Kconfig
index 79237842f7e2..af0dd42e3506 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -1016,10 +1016,10 @@ config ARCH_FORCE_MAX_ORDER
# as per include/linux/mmzone.h.
config PAGE_BLOCK_ORDER
int "Page Block Order"
- range 1 10 if !ARCH_FORCE_MAX_ORDER
- 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
+ range 1 10 if ARCH_FORCE_MAX_ORDER = 0
+ default 10 if ARCH_FORCE_MAX_ORDER = 0
+ range 1 ARCH_FORCE_MAX_ORDER if ARCH_FORCE_MAX_ORDER != 0
+ default ARCH_FORCE_MAX_ORDER if ARCH_FORCE_MAX_ORDER != 0
help
The page block order refers to the power of two number of pages that
--
2.47.2
--
Best Regards,
Yan, Zi
On Sat, May 17, 2025 at 11:51 AM Zi Yan <ziy@nvidia.com> wrote:
>
> On 9 May 2025, at 21:02, 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 them.
> >
> > 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) = 4MiB
> > 16Kib | 11 | 11 | 16KiB * (2 ^ 11) = 32MiB
> > 64KiB | 13 | 13 | 64KiB * (2 ^ 13) = 512MiB
> >
> > 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) = 128MiB
> > 16Kib | 13 | 13 | 16KiB * (2 ^ 13) = 128MiB
> > 64KiB | 13 | 13 | 64KiB * (2 ^ 13) = 512MiB
> >
> > 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 = "shared-dma-pool";
> > size = <0x0 0x400000>; /* 4 MiB */
> > ...
> > };
> > };
> >
> > reserved-memory {
> > ...
> > cma_test_reserve: cma_test_reserve {
> > compatible = "shared-dma-pool";
> > size = <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 = -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 times
> > 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 <akpm@linux-foundation.org>
> > Cc: Vlastimil Babka <vbabka@suse.cz>
> > Cc: Liam R. Howlett <Liam.Howlett@oracle.com>
> > Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> > Cc: David Hildenbrand <david@redhat.com>
> > CC: Mike Rapoport <rppt@kernel.org>
> > Cc: Zi Yan <ziy@nvidia.com>
> > Cc: Suren Baghdasaryan <surenb@google.com>
> > Cc: Minchan Kim <minchan@kernel.org>
> > Signed-off-by: Juan Yescas <jyescas@google.com>
> > Acked-by: Zi Yan <ziy@nvidia.com>
> > ---
> > Changes in v4:
> > - Set PAGE_BLOCK_ORDER in incluxe/linux/mmzone.h to
> > validate that MAX_PAGE_ORDER >= PAGE_BLOCK_ORDER at
> > compile time.
> > - This change fixes the warning in:
> > https://lore.kernel.org/oe-kbuild-all/202505091548.FuKO4b4v-lkp@intel.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 | 31 +++++++++++++++++++++++++++++++
> > 3 files changed, 51 insertions(+), 4 deletions(-)
>
> Hi Juan,
>
> The patch below on top of your v4 fixed powerpc build issue, as I tested
> it locally.
>
> From 5c2ae4dfca135e99da45302e4f5d96a315a99603 Mon Sep 17 00:00:00 2001
> From: Zi Yan <ziy@nvidia.com>
> Date: Sat, 17 May 2025 14:49:39 -0400
> Subject: [PATCH] fix CONFIG_PAGE_BLOCK_ORDER
>
> Signed-off-by: Zi Yan <ziy@nvidia.com>
> ---
> mm/Kconfig | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 79237842f7e2..af0dd42e3506 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -1016,10 +1016,10 @@ config ARCH_FORCE_MAX_ORDER
> # as per include/linux/mmzone.h.
> config PAGE_BLOCK_ORDER
> int "Page Block Order"
> - range 1 10 if !ARCH_FORCE_MAX_ORDER
> - 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
> + range 1 10 if ARCH_FORCE_MAX_ORDER = 0
> + default 10 if ARCH_FORCE_MAX_ORDER = 0
> + range 1 ARCH_FORCE_MAX_ORDER if ARCH_FORCE_MAX_ORDER != 0
> + default ARCH_FORCE_MAX_ORDER if ARCH_FORCE_MAX_ORDER != 0
>
> help
> The page block order refers to the power of two number of pages that
> --
> 2.47.2
>
Thanks Zi, the changes were applied in v6
https://lore.kernel.org/all/20250520225945.991229-1-jyescas@google.com/
>
>
>
> --
> Best Regards,
> Yan, Zi
Hi Juan,
kernel test robot noticed the following build errors:
[auto build test ERROR on linus/master]
[also build test ERROR on v6.15-rc5]
[cannot apply to akpm-mm/mm-everything next-20250509]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Juan-Yescas/mm-Add-CONFIG_PAGE_BLOCK_ORDER-to-select-page-block-order/20250510-090501
base: linus/master
patch link: https://lore.kernel.org/r/20250510010338.3978696-1-jyescas%40google.com
patch subject: [PATCH v4] mm: Add CONFIG_PAGE_BLOCK_ORDER to select page block order
config: powerpc-allmodconfig (https://download.01.org/0day-ci/archive/20250511/202505110035.wtOWnL8o-lkp@intel.com/config)
compiler: powerpc64-linux-gcc (GCC) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250511/202505110035.wtOWnL8o-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202505110035.wtOWnL8o-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from include/linux/gfp.h:7,
from include/linux/xarray.h:16,
from include/linux/list_lru.h:14,
from include/linux/fs.h:14,
from include/linux/compat.h:17,
from arch/powerpc/kernel/asm-offsets.c:12:
>> include/linux/mmzone.h:53:2: error: #error MAX_PAGE_ORDER must be >= PAGE_BLOCK_ORDER
53 | #error MAX_PAGE_ORDER must be >= PAGE_BLOCK_ORDER
| ^~~~~
make[3]: *** [scripts/Makefile.build:98: arch/powerpc/kernel/asm-offsets.s] Error 1
make[3]: Target 'prepare' not remade because of errors.
make[2]: *** [Makefile:1275: prepare0] Error 2
make[2]: Target 'prepare' not remade because of errors.
make[1]: *** [Makefile:248: __sub-make] Error 2
make[1]: Target 'prepare' not remade because of errors.
make: *** [Makefile:248: __sub-make] Error 2
make: Target 'prepare' not remade because of errors.
vim +53 include/linux/mmzone.h
46
47 /*
48 * The MAX_PAGE_ORDER, which defines the max order of pages to be allocated
49 * by the buddy allocator, has to be larger or equal to the PAGE_BLOCK_ORDER,
50 * which defines the order for the number of pages that can have a migrate type
51 */
52 #if (PAGE_BLOCK_ORDER > MAX_PAGE_ORDER)
> 53 #error MAX_PAGE_ORDER must be >= PAGE_BLOCK_ORDER
54 #endif
55
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
On 10 May 2025, at 13:16, kernel test robot wrote: > Hi Juan, > > kernel test robot noticed the following build errors: > > [auto build test ERROR on linus/master] > [also build test ERROR on v6.15-rc5] > [cannot apply to akpm-mm/mm-everything next-20250509] > [If your patch is applied to the wrong git tree, kindly drop us a note. > And when submitting patch, we suggest to use '--base' as documented in > https://git-scm.com/docs/git-format-patch#_base_tree_information] > > url: https://github.com/intel-lab-lkp/linux/commits/Juan-Yescas/mm-Add-CONFIG_PAGE_BLOCK_ORDER-to-select-page-block-order/20250510-090501 > base: linus/master > patch link: https://lore.kernel.org/r/20250510010338.3978696-1-jyescas%40google.com > patch subject: [PATCH v4] mm: Add CONFIG_PAGE_BLOCK_ORDER to select page block order > config: powerpc-allmodconfig (https://download.01.org/0day-ci/archive/20250511/202505110035.wtOWnL8o-lkp@intel.com/config) > compiler: powerpc64-linux-gcc (GCC) 14.2.0 > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250511/202505110035.wtOWnL8o-lkp@intel.com/reproduce) > > If you fix the issue in a separate patch/commit (i.e. not just a new version of > the same patch/commit), kindly add following tags > | Reported-by: kernel test robot <lkp@intel.com> > | Closes: https://lore.kernel.org/oe-kbuild-all/202505110035.wtOWnL8o-lkp@intel.com/ > > All errors (new ones prefixed by >>): > > In file included from include/linux/gfp.h:7, > from include/linux/xarray.h:16, > from include/linux/list_lru.h:14, > from include/linux/fs.h:14, > from include/linux/compat.h:17, > from arch/powerpc/kernel/asm-offsets.c:12: >>> include/linux/mmzone.h:53:2: error: #error MAX_PAGE_ORDER must be >= PAGE_BLOCK_ORDER > 53 | #error MAX_PAGE_ORDER must be >= PAGE_BLOCK_ORDER > | ^~~~~ > make[3]: *** [scripts/Makefile.build:98: arch/powerpc/kernel/asm-offsets.s] Error 1 In this config, CONFIG_ARCH_FORCE_MAX_ORDER is set to 8, lower than the default PAGE_BLOCK_ORDER value, 10. I wonder if the error should be changed to ignore CONFIG_PAGE_BLOCK_ORDER when MAX_PAGE_ORDER is set by CONFIG_ARCH_FORCE_MAX_ORDER and give a warning instead. > make[3]: Target 'prepare' not remade because of errors. > make[2]: *** [Makefile:1275: prepare0] Error 2 > make[2]: Target 'prepare' not remade because of errors. > make[1]: *** [Makefile:248: __sub-make] Error 2 > make[1]: Target 'prepare' not remade because of errors. > make: *** [Makefile:248: __sub-make] Error 2 > make: Target 'prepare' not remade because of errors. > > > vim +53 include/linux/mmzone.h > > 46 > 47 /* > 48 * The MAX_PAGE_ORDER, which defines the max order of pages to be allocated > 49 * by the buddy allocator, has to be larger or equal to the PAGE_BLOCK_ORDER, > 50 * which defines the order for the number of pages that can have a migrate type > 51 */ > 52 #if (PAGE_BLOCK_ORDER > MAX_PAGE_ORDER) > > 53 #error MAX_PAGE_ORDER must be >= PAGE_BLOCK_ORDER > 54 #endif > 55 > > -- > 0-DAY CI Kernel Test Service > https://github.com/intel/lkp-tests/wiki Best Regards, Yan, Zi
On Tue, May 13, 2025 at 8:08 AM Zi Yan <ziy@nvidia.com> wrote: > > On 10 May 2025, at 13:16, kernel test robot wrote: > > > Hi Juan, > > > > kernel test robot noticed the following build errors: > > > > [auto build test ERROR on linus/master] > > [also build test ERROR on v6.15-rc5] > > [cannot apply to akpm-mm/mm-everything next-20250509] > > [If your patch is applied to the wrong git tree, kindly drop us a note. > > And when submitting patch, we suggest to use '--base' as documented in > > https://git-scm.com/docs/git-format-patch#_base_tree_information] > > > > url: https://github.com/intel-lab-lkp/linux/commits/Juan-Yescas/mm-Add-CONFIG_PAGE_BLOCK_ORDER-to-select-page-block-order/20250510-090501 > > base: linus/master > > patch link: https://lore.kernel.org/r/20250510010338.3978696-1-jyescas%40google.com > > patch subject: [PATCH v4] mm: Add CONFIG_PAGE_BLOCK_ORDER to select page block order > > config: powerpc-allmodconfig (https://download.01.org/0day-ci/archive/20250511/202505110035.wtOWnL8o-lkp@intel.com/config) > > compiler: powerpc64-linux-gcc (GCC) 14.2.0 > > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250511/202505110035.wtOWnL8o-lkp@intel.com/reproduce) > > > > If you fix the issue in a separate patch/commit (i.e. not just a new version of > > the same patch/commit), kindly add following tags > > | Reported-by: kernel test robot <lkp@intel.com> > > | Closes: https://lore.kernel.org/oe-kbuild-all/202505110035.wtOWnL8o-lkp@intel.com/ > > > > All errors (new ones prefixed by >>): > > > > In file included from include/linux/gfp.h:7, > > from include/linux/xarray.h:16, > > from include/linux/list_lru.h:14, > > from include/linux/fs.h:14, > > from include/linux/compat.h:17, > > from arch/powerpc/kernel/asm-offsets.c:12: > >>> include/linux/mmzone.h:53:2: error: #error MAX_PAGE_ORDER must be >= PAGE_BLOCK_ORDER > > 53 | #error MAX_PAGE_ORDER must be >= PAGE_BLOCK_ORDER > > | ^~~~~ > > make[3]: *** [scripts/Makefile.build:98: arch/powerpc/kernel/asm-offsets.s] Error 1 > > In this config, CONFIG_ARCH_FORCE_MAX_ORDER is set to 8, lower than > the default PAGE_BLOCK_ORDER value, 10. I wonder if the error should > be changed to ignore CONFIG_PAGE_BLOCK_ORDER when MAX_PAGE_ORDER is > set by CONFIG_ARCH_FORCE_MAX_ORDER and give a warning instead. In ARMv8, MAX_PAGE_ORDER is set up by CONFIG_ARCH_FORCE_MAX_ORDER and CONFIG_PAGE_BLOCK_ORDER is also set up, so we need to take into account CONFIG_PAGE_BLOCK_ORDER. For other architectures, the default will be: CONFIG_ARCH_FORCE_MAX_ORDER = CONFIG_PAGE_BLOCK_ORDER. Is there any valid case where the MAX_PAGE_ORDER needs to be smaller than the page block order? Thanks Juan > > > make[3]: Target 'prepare' not remade because of errors. > > make[2]: *** [Makefile:1275: prepare0] Error 2 > > make[2]: Target 'prepare' not remade because of errors. > > make[1]: *** [Makefile:248: __sub-make] Error 2 > > make[1]: Target 'prepare' not remade because of errors. > > make: *** [Makefile:248: __sub-make] Error 2 > > make: Target 'prepare' not remade because of errors. > > > > > > vim +53 include/linux/mmzone.h > > > > 46 > > 47 /* > > 48 * The MAX_PAGE_ORDER, which defines the max order of pages to be allocated > > 49 * by the buddy allocator, has to be larger or equal to the PAGE_BLOCK_ORDER, > > 50 * which defines the order for the number of pages that can have a migrate type > > 51 */ > > 52 #if (PAGE_BLOCK_ORDER > MAX_PAGE_ORDER) > > > 53 #error MAX_PAGE_ORDER must be >= PAGE_BLOCK_ORDER > > 54 #endif > > 55 > > > > -- > > 0-DAY CI Kernel Test Service > > https://github.com/intel/lkp-tests/wiki > > > Best Regards, > Yan, Zi
On 13 May 2025, at 12:41, Juan Yescas wrote: > On Tue, May 13, 2025 at 8:08 AM Zi Yan <ziy@nvidia.com> wrote: >> >> On 10 May 2025, at 13:16, kernel test robot wrote: >> >>> Hi Juan, >>> >>> kernel test robot noticed the following build errors: >>> >>> [auto build test ERROR on linus/master] >>> [also build test ERROR on v6.15-rc5] >>> [cannot apply to akpm-mm/mm-everything next-20250509] >>> [If your patch is applied to the wrong git tree, kindly drop us a note. >>> And when submitting patch, we suggest to use '--base' as documented in >>> https://git-scm.com/docs/git-format-patch#_base_tree_information] >>> >>> url: https://github.com/intel-lab-lkp/linux/commits/Juan-Yescas/mm-Add-CONFIG_PAGE_BLOCK_ORDER-to-select-page-block-order/20250510-090501 >>> base: linus/master >>> patch link: https://lore.kernel.org/r/20250510010338.3978696-1-jyescas%40google.com >>> patch subject: [PATCH v4] mm: Add CONFIG_PAGE_BLOCK_ORDER to select page block order >>> config: powerpc-allmodconfig (https://download.01.org/0day-ci/archive/20250511/202505110035.wtOWnL8o-lkp@intel.com/config) >>> compiler: powerpc64-linux-gcc (GCC) 14.2.0 >>> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250511/202505110035.wtOWnL8o-lkp@intel.com/reproduce) >>> >>> If you fix the issue in a separate patch/commit (i.e. not just a new version of >>> the same patch/commit), kindly add following tags >>> | Reported-by: kernel test robot <lkp@intel.com> >>> | Closes: https://lore.kernel.org/oe-kbuild-all/202505110035.wtOWnL8o-lkp@intel.com/ >>> >>> All errors (new ones prefixed by >>): >>> >>> In file included from include/linux/gfp.h:7, >>> from include/linux/xarray.h:16, >>> from include/linux/list_lru.h:14, >>> from include/linux/fs.h:14, >>> from include/linux/compat.h:17, >>> from arch/powerpc/kernel/asm-offsets.c:12: >>>>> include/linux/mmzone.h:53:2: error: #error MAX_PAGE_ORDER must be >= PAGE_BLOCK_ORDER >>> 53 | #error MAX_PAGE_ORDER must be >= PAGE_BLOCK_ORDER >>> | ^~~~~ >>> make[3]: *** [scripts/Makefile.build:98: arch/powerpc/kernel/asm-offsets.s] Error 1 >> >> In this config, CONFIG_ARCH_FORCE_MAX_ORDER is set to 8, lower than >> the default PAGE_BLOCK_ORDER value, 10. I wonder if the error should >> be changed to ignore CONFIG_PAGE_BLOCK_ORDER when MAX_PAGE_ORDER is >> set by CONFIG_ARCH_FORCE_MAX_ORDER and give a warning instead. > > In ARMv8, MAX_PAGE_ORDER is set up by CONFIG_ARCH_FORCE_MAX_ORDER > and CONFIG_PAGE_BLOCK_ORDER is also set up, so we need to take into account > CONFIG_PAGE_BLOCK_ORDER. For other architectures, the default will be: > CONFIG_ARCH_FORCE_MAX_ORDER = CONFIG_PAGE_BLOCK_ORDER. It seems that the Kconfig “range 1 ARCH_FORCE_MAX_ORDER if ARCH_FORCE_MAX_ORDER” is not working. The above powerpc-allmodconfig has CONFIG_ARCH_FORCE_MAX_ORDER set to 8 and CONFIG_PAGE_BLOCK_ORDER is set to 10, leading to the compilation error. > > Is there any valid case where the MAX_PAGE_ORDER needs to be smaller than > the page block order? I am not aware of any. > > Thanks > Juan >> >>> make[3]: Target 'prepare' not remade because of errors. >>> make[2]: *** [Makefile:1275: prepare0] Error 2 >>> make[2]: Target 'prepare' not remade because of errors. >>> make[1]: *** [Makefile:248: __sub-make] Error 2 >>> make[1]: Target 'prepare' not remade because of errors. >>> make: *** [Makefile:248: __sub-make] Error 2 >>> make: Target 'prepare' not remade because of errors. >>> >>> >>> vim +53 include/linux/mmzone.h >>> >>> 46 >>> 47 /* >>> 48 * The MAX_PAGE_ORDER, which defines the max order of pages to be allocated >>> 49 * by the buddy allocator, has to be larger or equal to the PAGE_BLOCK_ORDER, >>> 50 * which defines the order for the number of pages that can have a migrate type >>> 51 */ >>> 52 #if (PAGE_BLOCK_ORDER > MAX_PAGE_ORDER) >>> > 53 #error MAX_PAGE_ORDER must be >= PAGE_BLOCK_ORDER >>> 54 #endif >>> 55 >>> >>> -- >>> 0-DAY CI Kernel Test Service >>> https://github.com/intel/lkp-tests/wiki >> >> >> Best Regards, >> Yan, Zi Best Regards, Yan, Zi
On Tue, May 13, 2025 at 9:47 AM Zi Yan <ziy@nvidia.com> wrote: > > On 13 May 2025, at 12:41, Juan Yescas wrote: > > > On Tue, May 13, 2025 at 8:08 AM Zi Yan <ziy@nvidia.com> wrote: > >> > >> On 10 May 2025, at 13:16, kernel test robot wrote: > >> > >>> Hi Juan, > >>> > >>> kernel test robot noticed the following build errors: > >>> > >>> [auto build test ERROR on linus/master] > >>> [also build test ERROR on v6.15-rc5] > >>> [cannot apply to akpm-mm/mm-everything next-20250509] > >>> [If your patch is applied to the wrong git tree, kindly drop us a note. > >>> And when submitting patch, we suggest to use '--base' as documented in > >>> https://git-scm.com/docs/git-format-patch#_base_tree_information] > >>> > >>> url: https://github.com/intel-lab-lkp/linux/commits/Juan-Yescas/mm-Add-CONFIG_PAGE_BLOCK_ORDER-to-select-page-block-order/20250510-090501 > >>> base: linus/master > >>> patch link: https://lore.kernel.org/r/20250510010338.3978696-1-jyescas%40google.com > >>> patch subject: [PATCH v4] mm: Add CONFIG_PAGE_BLOCK_ORDER to select page block order > >>> config: powerpc-allmodconfig (https://download.01.org/0day-ci/archive/20250511/202505110035.wtOWnL8o-lkp@intel.com/config) > >>> compiler: powerpc64-linux-gcc (GCC) 14.2.0 > >>> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250511/202505110035.wtOWnL8o-lkp@intel.com/reproduce) > >>> > >>> If you fix the issue in a separate patch/commit (i.e. not just a new version of > >>> the same patch/commit), kindly add following tags > >>> | Reported-by: kernel test robot <lkp@intel.com> > >>> | Closes: https://lore.kernel.org/oe-kbuild-all/202505110035.wtOWnL8o-lkp@intel.com/ > >>> > >>> All errors (new ones prefixed by >>): > >>> > >>> In file included from include/linux/gfp.h:7, > >>> from include/linux/xarray.h:16, > >>> from include/linux/list_lru.h:14, > >>> from include/linux/fs.h:14, > >>> from include/linux/compat.h:17, > >>> from arch/powerpc/kernel/asm-offsets.c:12: > >>>>> include/linux/mmzone.h:53:2: error: #error MAX_PAGE_ORDER must be >= PAGE_BLOCK_ORDER > >>> 53 | #error MAX_PAGE_ORDER must be >= PAGE_BLOCK_ORDER > >>> | ^~~~~ > >>> make[3]: *** [scripts/Makefile.build:98: arch/powerpc/kernel/asm-offsets.s] Error 1 > >> > >> In this config, CONFIG_ARCH_FORCE_MAX_ORDER is set to 8, lower than > >> the default PAGE_BLOCK_ORDER value, 10. I wonder if the error should > >> be changed to ignore CONFIG_PAGE_BLOCK_ORDER when MAX_PAGE_ORDER is > >> set by CONFIG_ARCH_FORCE_MAX_ORDER and give a warning instead. > > > > In ARMv8, MAX_PAGE_ORDER is set up by CONFIG_ARCH_FORCE_MAX_ORDER > > and CONFIG_PAGE_BLOCK_ORDER is also set up, so we need to take into account > > CONFIG_PAGE_BLOCK_ORDER. For other architectures, the default will be: > > CONFIG_ARCH_FORCE_MAX_ORDER = CONFIG_PAGE_BLOCK_ORDER. > > It seems that the Kconfig “range 1 ARCH_FORCE_MAX_ORDER if ARCH_FORCE_MAX_ORDER” > is not working. The above powerpc-allmodconfig has CONFIG_ARCH_FORCE_MAX_ORDER > set to 8 and CONFIG_PAGE_BLOCK_ORDER is set to 10, leading to the compilation > error. > Right, Kconfig restriction is being ignored by powerpc, however, it is respected by ARMv8. The main difference that I see between arch/arm64/Kconfig and arch/powerpc/Kconfig is that powerpc/Kconfig is using ranges, but not in arm64/Kconfig https://elixir.bootlin.com/linux/v6.14.6/source/arch/arm64/Kconfig#L1637 config ARCH_FORCE_MAX_ORDER int default "13" if ARM64_64K_PAGES default "11" if ARM64_16K_PAGES default "10" https://elixir.bootlin.com/linux/v6.14.6/source/arch/powerpc/Kconfig#L918 config ARCH_FORCE_MAX_ORDER int "Order of maximal physically contiguous allocations" range 7 8 if PPC64 && PPC_64K_PAGES default "8" if PPC64 && PPC_64K_PAGES range 12 12 if PPC64 && !PPC_64K_PAGES default "12" if PPC64 && !PPC_64K_PAGES range 8 10 if PPC32 && PPC_16K_PAGES > > > > Is there any valid case where the MAX_PAGE_ORDER needs to be smaller than > > the page block order? > > I am not aware of any. > > > > > Thanks > > Juan > >> > >>> make[3]: Target 'prepare' not remade because of errors. > >>> make[2]: *** [Makefile:1275: prepare0] Error 2 > >>> make[2]: Target 'prepare' not remade because of errors. > >>> make[1]: *** [Makefile:248: __sub-make] Error 2 > >>> make[1]: Target 'prepare' not remade because of errors. > >>> make: *** [Makefile:248: __sub-make] Error 2 > >>> make: Target 'prepare' not remade because of errors. > >>> > >>> > >>> vim +53 include/linux/mmzone.h > >>> > >>> 46 > >>> 47 /* > >>> 48 * The MAX_PAGE_ORDER, which defines the max order of pages to be allocated > >>> 49 * by the buddy allocator, has to be larger or equal to the PAGE_BLOCK_ORDER, > >>> 50 * which defines the order for the number of pages that can have a migrate type > >>> 51 */ > >>> 52 #if (PAGE_BLOCK_ORDER > MAX_PAGE_ORDER) > >>> > 53 #error MAX_PAGE_ORDER must be >= PAGE_BLOCK_ORDER > >>> 54 #endif > >>> 55 > >>> > >>> -- > >>> 0-DAY CI Kernel Test Service > >>> https://github.com/intel/lkp-tests/wiki > >> > >> > >> Best Regards, > >> Yan, Zi > > > Best Regards, > Yan, Zi
On 13 May 2025, at 12:47, Zi Yan wrote: > On 13 May 2025, at 12:41, Juan Yescas wrote: > >> On Tue, May 13, 2025 at 8:08 AM Zi Yan <ziy@nvidia.com> wrote: >>> >>> On 10 May 2025, at 13:16, kernel test robot wrote: >>> >>>> Hi Juan, >>>> >>>> kernel test robot noticed the following build errors: >>>> >>>> [auto build test ERROR on linus/master] >>>> [also build test ERROR on v6.15-rc5] >>>> [cannot apply to akpm-mm/mm-everything next-20250509] >>>> [If your patch is applied to the wrong git tree, kindly drop us a note. >>>> And when submitting patch, we suggest to use '--base' as documented in >>>> https://git-scm.com/docs/git-format-patch#_base_tree_information] >>>> >>>> url: https://github.com/intel-lab-lkp/linux/commits/Juan-Yescas/mm-Add-CONFIG_PAGE_BLOCK_ORDER-to-select-page-block-order/20250510-090501 >>>> base: linus/master >>>> patch link: https://lore.kernel.org/r/20250510010338.3978696-1-jyescas%40google.com >>>> patch subject: [PATCH v4] mm: Add CONFIG_PAGE_BLOCK_ORDER to select page block order >>>> config: powerpc-allmodconfig (https://download.01.org/0day-ci/archive/20250511/202505110035.wtOWnL8o-lkp@intel.com/config) >>>> compiler: powerpc64-linux-gcc (GCC) 14.2.0 >>>> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250511/202505110035.wtOWnL8o-lkp@intel.com/reproduce) >>>> >>>> If you fix the issue in a separate patch/commit (i.e. not just a new version of >>>> the same patch/commit), kindly add following tags >>>> | Reported-by: kernel test robot <lkp@intel.com> >>>> | Closes: https://lore.kernel.org/oe-kbuild-all/202505110035.wtOWnL8o-lkp@intel.com/ >>>> >>>> All errors (new ones prefixed by >>): >>>> >>>> In file included from include/linux/gfp.h:7, >>>> from include/linux/xarray.h:16, >>>> from include/linux/list_lru.h:14, >>>> from include/linux/fs.h:14, >>>> from include/linux/compat.h:17, >>>> from arch/powerpc/kernel/asm-offsets.c:12: >>>>>> include/linux/mmzone.h:53:2: error: #error MAX_PAGE_ORDER must be >= PAGE_BLOCK_ORDER >>>> 53 | #error MAX_PAGE_ORDER must be >= PAGE_BLOCK_ORDER >>>> | ^~~~~ >>>> make[3]: *** [scripts/Makefile.build:98: arch/powerpc/kernel/asm-offsets.s] Error 1 >>> >>> In this config, CONFIG_ARCH_FORCE_MAX_ORDER is set to 8, lower than >>> the default PAGE_BLOCK_ORDER value, 10. I wonder if the error should >>> be changed to ignore CONFIG_PAGE_BLOCK_ORDER when MAX_PAGE_ORDER is >>> set by CONFIG_ARCH_FORCE_MAX_ORDER and give a warning instead. >> >> In ARMv8, MAX_PAGE_ORDER is set up by CONFIG_ARCH_FORCE_MAX_ORDER >> and CONFIG_PAGE_BLOCK_ORDER is also set up, so we need to take into account >> CONFIG_PAGE_BLOCK_ORDER. For other architectures, the default will be: >> CONFIG_ARCH_FORCE_MAX_ORDER = CONFIG_PAGE_BLOCK_ORDER. > > It seems that the Kconfig “range 1 ARCH_FORCE_MAX_ORDER if ARCH_FORCE_MAX_ORDER” > is not working. The above powerpc-allmodconfig has CONFIG_ARCH_FORCE_MAX_ORDER > set to 8 and CONFIG_PAGE_BLOCK_ORDER is set to 10, leading to the compilation > error. You can get the same config by running “ARCH=powerpc make allmodconfig”. > >> >> Is there any valid case where the MAX_PAGE_ORDER needs to be smaller than >> the page block order? > > I am not aware of any. > >> >> Thanks >> Juan >>> >>>> make[3]: Target 'prepare' not remade because of errors. >>>> make[2]: *** [Makefile:1275: prepare0] Error 2 >>>> make[2]: Target 'prepare' not remade because of errors. >>>> make[1]: *** [Makefile:248: __sub-make] Error 2 >>>> make[1]: Target 'prepare' not remade because of errors. >>>> make: *** [Makefile:248: __sub-make] Error 2 >>>> make: Target 'prepare' not remade because of errors. >>>> >>>> >>>> vim +53 include/linux/mmzone.h >>>> >>>> 46 >>>> 47 /* >>>> 48 * The MAX_PAGE_ORDER, which defines the max order of pages to be allocated >>>> 49 * by the buddy allocator, has to be larger or equal to the PAGE_BLOCK_ORDER, >>>> 50 * which defines the order for the number of pages that can have a migrate type >>>> 51 */ >>>> 52 #if (PAGE_BLOCK_ORDER > MAX_PAGE_ORDER) >>>> > 53 #error MAX_PAGE_ORDER must be >= PAGE_BLOCK_ORDER >>>> 54 #endif >>>> 55 >>>> >>>> -- >>>> 0-DAY CI Kernel Test Service >>>> https://github.com/intel/lkp-tests/wiki >>> >>> >>> Best Regards, >>> Yan, Zi > > > Best Regards, > Yan, Zi Best Regards, Yan, Zi
On Tue, May 13, 2025 at 9:52 AM Zi Yan <ziy@nvidia.com> wrote: > > On 13 May 2025, at 12:47, Zi Yan wrote: > > > On 13 May 2025, at 12:41, Juan Yescas wrote: > > > >> On Tue, May 13, 2025 at 8:08 AM Zi Yan <ziy@nvidia.com> wrote: > >>> > >>> On 10 May 2025, at 13:16, kernel test robot wrote: > >>> > >>>> Hi Juan, > >>>> > >>>> kernel test robot noticed the following build errors: > >>>> > >>>> [auto build test ERROR on linus/master] > >>>> [also build test ERROR on v6.15-rc5] > >>>> [cannot apply to akpm-mm/mm-everything next-20250509] > >>>> [If your patch is applied to the wrong git tree, kindly drop us a note. > >>>> And when submitting patch, we suggest to use '--base' as documented in > >>>> https://git-scm.com/docs/git-format-patch#_base_tree_information] > >>>> > >>>> url: https://github.com/intel-lab-lkp/linux/commits/Juan-Yescas/mm-Add-CONFIG_PAGE_BLOCK_ORDER-to-select-page-block-order/20250510-090501 > >>>> base: linus/master > >>>> patch link: https://lore.kernel.org/r/20250510010338.3978696-1-jyescas%40google.com > >>>> patch subject: [PATCH v4] mm: Add CONFIG_PAGE_BLOCK_ORDER to select page block order > >>>> config: powerpc-allmodconfig (https://download.01.org/0day-ci/archive/20250511/202505110035.wtOWnL8o-lkp@intel.com/config) > >>>> compiler: powerpc64-linux-gcc (GCC) 14.2.0 > >>>> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250511/202505110035.wtOWnL8o-lkp@intel.com/reproduce) > >>>> > >>>> If you fix the issue in a separate patch/commit (i.e. not just a new version of > >>>> the same patch/commit), kindly add following tags > >>>> | Reported-by: kernel test robot <lkp@intel.com> > >>>> | Closes: https://lore.kernel.org/oe-kbuild-all/202505110035.wtOWnL8o-lkp@intel.com/ > >>>> > >>>> All errors (new ones prefixed by >>): > >>>> > >>>> In file included from include/linux/gfp.h:7, > >>>> from include/linux/xarray.h:16, > >>>> from include/linux/list_lru.h:14, > >>>> from include/linux/fs.h:14, > >>>> from include/linux/compat.h:17, > >>>> from arch/powerpc/kernel/asm-offsets.c:12: > >>>>>> include/linux/mmzone.h:53:2: error: #error MAX_PAGE_ORDER must be >= PAGE_BLOCK_ORDER > >>>> 53 | #error MAX_PAGE_ORDER must be >= PAGE_BLOCK_ORDER > >>>> | ^~~~~ > >>>> make[3]: *** [scripts/Makefile.build:98: arch/powerpc/kernel/asm-offsets.s] Error 1 > >>> > >>> In this config, CONFIG_ARCH_FORCE_MAX_ORDER is set to 8, lower than > >>> the default PAGE_BLOCK_ORDER value, 10. I wonder if the error should > >>> be changed to ignore CONFIG_PAGE_BLOCK_ORDER when MAX_PAGE_ORDER is > >>> set by CONFIG_ARCH_FORCE_MAX_ORDER and give a warning instead. > >> > >> In ARMv8, MAX_PAGE_ORDER is set up by CONFIG_ARCH_FORCE_MAX_ORDER > >> and CONFIG_PAGE_BLOCK_ORDER is also set up, so we need to take into account > >> CONFIG_PAGE_BLOCK_ORDER. For other architectures, the default will be: > >> CONFIG_ARCH_FORCE_MAX_ORDER = CONFIG_PAGE_BLOCK_ORDER. > > > > It seems that the Kconfig “range 1 ARCH_FORCE_MAX_ORDER if ARCH_FORCE_MAX_ORDER” > > is not working. The above powerpc-allmodconfig has CONFIG_ARCH_FORCE_MAX_ORDER > > set to 8 and CONFIG_PAGE_BLOCK_ORDER is set to 10, leading to the compilation > > error. > > You can get the same config by running “ARCH=powerpc make allmodconfig”. > Thanks, that works! > > > >> > >> Is there any valid case where the MAX_PAGE_ORDER needs to be smaller than > >> the page block order? > > > > I am not aware of any. > > > >> > >> Thanks > >> Juan > >>> > >>>> make[3]: Target 'prepare' not remade because of errors. > >>>> make[2]: *** [Makefile:1275: prepare0] Error 2 > >>>> make[2]: Target 'prepare' not remade because of errors. > >>>> make[1]: *** [Makefile:248: __sub-make] Error 2 > >>>> make[1]: Target 'prepare' not remade because of errors. > >>>> make: *** [Makefile:248: __sub-make] Error 2 > >>>> make: Target 'prepare' not remade because of errors. > >>>> > >>>> > >>>> vim +53 include/linux/mmzone.h > >>>> > >>>> 46 > >>>> 47 /* > >>>> 48 * The MAX_PAGE_ORDER, which defines the max order of pages to be allocated > >>>> 49 * by the buddy allocator, has to be larger or equal to the PAGE_BLOCK_ORDER, > >>>> 50 * which defines the order for the number of pages that can have a migrate type > >>>> 51 */ > >>>> 52 #if (PAGE_BLOCK_ORDER > MAX_PAGE_ORDER) > >>>> > 53 #error MAX_PAGE_ORDER must be >= PAGE_BLOCK_ORDER > >>>> 54 #endif > >>>> 55 > >>>> > >>>> -- > >>>> 0-DAY CI Kernel Test Service > >>>> https://github.com/intel/lkp-tests/wiki > >>> > >>> > >>> Best Regards, > >>> Yan, Zi > > > > > > Best Regards, > > Yan, Zi > > > Best Regards, > Yan, Zi
© 2016 - 2025 Red Hat, Inc.