Re: [PATCH v1 2/2] mm: enforce pageblock_order < MAX_ORDER

[Zi Yan]

On 14 Feb 2022, at 12:41, David Hildenbrand wrote:

> Some places in the kernel don't really expect pageblock_order >=
> MAX_ORDER, and it looks like this is only possible in corner cases:
>
> 1) CONFIG_DEFERRED_STRUCT_PAGE_INIT we'll end up freeing pageblock_order
>    pages via __free_pages_core(), which cannot possibly work.
>
> 2) find_zone_movable_pfns_for_nodes() will roundup the ZONE_MOVABLE
>    start PFN to MAX_ORDER_NR_PAGES. Consequently with a bigger
>    pageblock_order, we could have a single pageblock partially managed by
>    two zones.
>
> 3) compaction code runs into __fragmentation_index() with order
>    >= MAX_ORDER, when checking WARN_ON_ONCE(order >= MAX_ORDER). [1]
>
> 4) mm/page_reporting.c won't be reporting any pages with default
>    page_reporting_order == pageblock_order, as we'll be skipping the
>    reporting loop inside page_reporting_process_zone().
>
> 5) __rmqueue_fallback() will never be able to steal with
>    ALLOC_NOFRAGMENT.
>
> pageblock_order >= MAX_ORDER is weird either way: it's a pure
> optimization for making alloc_contig_range(), as used for allcoation of
> gigantic pages, a little more reliable to succeed. However, if there is
> demand for somewhat reliable allocation of gigantic pages, affected setups
> should be using CMA or boottime allocations instead.
>
> So let's make sure that pageblock_order < MAX_ORDER and simplify.
>
> [1] https://lkml.kernel.org/r/87r189a2ks.fsf@xxxxxxxxxxxxx
>
> Signed-off-by: David Hildenbrand <david@xxxxxxxxxx>
> ---
>  drivers/virtio/virtio_mem.c     |  9 +++------
>  include/linux/cma.h             |  3 +--
>  include/linux/pageblock-flags.h |  7 +++++--
>  mm/Kconfig                      |  3 +++
>  mm/page_alloc.c                 | 32 ++++++++------------------------
>  5 files changed, 20 insertions(+), 34 deletions(-)

LGTM. Thanks. Reviewed-by: Zi Yan <ziy@xxxxxxxxxx>

--
Best Regards,
Yan, Zi

Attachment: signature.asc
Description: OpenPGP digital signature