Message ID | 20241205085217.2086353-3-david@redhat.com (mailing list archive) |
---|---|
State | New |
Headers | show |
Series | mm: don't use __GFP_HARDWALL when migrating remote pages | expand |
On Thu, Dec 05, 2024 at 09:52:17AM +0100, David Hildenbrand wrote: > We'll migrate pages allocated by other context; respecting the cpuset of > the memory offlining context when allocating a migration target does not > make sense. > > Drop the __GFP_HARDWALL by using GFP_KERNEL. > > Note that in an ideal world, migration code could figure out the cpuset > of the original context and take that into consideration. > > Suggested-by: Vlastimil Babka <vbabka@suse.cz> > Signed-off-by: David Hildenbrand <david@redhat.com> Acked-by: Oscar Salvador <osalvador@suse.de>
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index 5f497ccf473d..3b6f93962481 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -1838,7 +1838,7 @@ static void do_migrate_range(unsigned long start_pfn, unsigned long end_pfn) nodemask_t nmask = node_states[N_MEMORY]; struct migration_target_control mtc = { .nmask = &nmask, - .gfp_mask = GFP_USER | __GFP_MOVABLE | __GFP_RETRY_MAYFAIL, + .gfp_mask = GFP_KERNEL | __GFP_MOVABLE | __GFP_RETRY_MAYFAIL, .reason = MR_MEMORY_HOTPLUG, }; int ret;
We'll migrate pages allocated by other context; respecting the cpuset of the memory offlining context when allocating a migration target does not make sense. Drop the __GFP_HARDWALL by using GFP_KERNEL. Note that in an ideal world, migration code could figure out the cpuset of the original context and take that into consideration. Suggested-by: Vlastimil Babka <vbabka@suse.cz> Signed-off-by: David Hildenbrand <david@redhat.com> --- mm/memory_hotplug.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)