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
