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....@linux.ibm.com > > Signed-off-by: David Hildenbrand <da...@redhat.com> > --- > 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 <z...@nvidia.com> -- Best Regards, Yan, Zi
signature.asc
Description: OpenPGP digital signature
_______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
