mm/page_alloc: don't use __GFP_HARDWALL when migrating pages via alloc_contig*()
authorDavid Hildenbrand <david@redhat.com>
Thu, 5 Dec 2024 09:05:07 +0000 (10:05 +0100)
committerAndrew Morton <akpm@linux-foundation.org>
Tue, 14 Jan 2025 06:40:53 +0000 (22:40 -0800)
commitf58498b72638262bd1b8d63143c5cf71761d57b7
tree202e34c9d438ea873da43f86f783f1d562fc470e
parentfa5d61791117177e4c6aa87f7d3c170fa6f1f43b
mm/page_alloc: don't use __GFP_HARDWALL when migrating pages via alloc_contig*()

Patch series "mm: don't use __GFP_HARDWALL when migrating remote pages".

__GFP_HARDWALL means that we will be respecting the cpuset of the caller
when allocating a page.  However, when we are migrating remote allocations
(pages allocated from other context), the cpuset of the current context is
irrelevant.

For memory offlining + alloc_contig_*(), this is rather obvious.  There
might be other such page migration users, let's start with the obvious
ones.

This patch (of 2):

We'll migrate pages allocated by other contexts; respecting the cpuset of
the alloc_contig*() caller when allocating a migration target does not
make sense.

Drop the __GFP_HARDWALL.

Note that in an ideal world, migration code could figure out the cpuset
of the original context and take that into consideration.

Link: https://lkml.kernel.org/r/20241205090508.2095225-1-david@redhat.com
Link: https://lkml.kernel.org/r/20241205090508.2095225-2-david@redhat.com
Signed-off-by: David Hildenbrand <david@redhat.com>
Suggested-by: Vlastimil Babka <vbabka@suse.cz>
Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
Reviewed-by: Oscar Salvador <osalvador@suse.de>
Cc: Zi Yan <ziy@nvidia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
mm/page_alloc.c