[PATCH RESEND v1 0/2] mm: don't use __GFP_HARDWALL when migrating remote pages

[PATCH RESEND v1 0/2] mm: don't use __GFP_HARDWALL when migrating remote pages

[David Hildenbrand]

Resending via a known-working SMTP setup.

---

__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.

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Zi Yan <ziy@nvidia.com>

David Hildenbrand (2):
  mm/page_alloc: don't use __GFP_HARDWALL when migrating pages via
    alloc_contig*()
  mm/memory_hotplug: don't use __GFP_HARDWALL when migrating pages via
    memory offlining

 mm/memory_hotplug.c | 2 +-
 mm/page_alloc.c     | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

-- 
2.47.1

[PATCH RESEND v1 1/2] mm/page_alloc: don't use __GFP_HARDWALL when migrating pages via alloc_contig*()

[David Hildenbrand]

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.

Suggested-by: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: David Hildenbrand <david@redhat.com>
---
 mm/page_alloc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 48a291c485df..acadfcf654fd 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6410,11 +6410,11 @@ static int __alloc_contig_verify_gfp_mask(gfp_t gfp_mask, gfp_t *gfp_cc_mask)
 	 * page range. Migratable pages are movable, __GFP_MOVABLE is implied
 	 * for them.
 	 *
-	 * Traditionally we always had __GFP_HARDWALL|__GFP_RETRY_MAYFAIL set,
-	 * keep doing that to not degrade callers.
+	 * Traditionally we always had __GFP_RETRY_MAYFAIL set, keep doing that
+	 * to not degrade callers.
 	 */
 	*gfp_cc_mask = (gfp_mask & (reclaim_mask | cc_action_mask)) |
-			__GFP_HARDWALL | __GFP_MOVABLE | __GFP_RETRY_MAYFAIL;
+			__GFP_MOVABLE | __GFP_RETRY_MAYFAIL;
 	return 0;
 }
 
-- 
2.47.1

Re: [PATCH RESEND v1 1/2] mm/page_alloc: don't use __GFP_HARDWALL when migrating pages via alloc_contig*()

[Vlastimil Babka]

On 12/5/24 10:05, David Hildenbrand wrote:
> 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.
> 
> Suggested-by: Vlastimil Babka <vbabka@suse.cz>
> Signed-off-by: David Hildenbrand <david@redhat.com>

Reviewed-by: Vlastimil Babka <vbabka@suse.cz>

> ---
>  mm/page_alloc.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 48a291c485df..acadfcf654fd 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -6410,11 +6410,11 @@ static int __alloc_contig_verify_gfp_mask(gfp_t gfp_mask, gfp_t *gfp_cc_mask)
>  	 * page range. Migratable pages are movable, __GFP_MOVABLE is implied
>  	 * for them.
>  	 *
> -	 * Traditionally we always had __GFP_HARDWALL|__GFP_RETRY_MAYFAIL set,
> -	 * keep doing that to not degrade callers.
> +	 * Traditionally we always had __GFP_RETRY_MAYFAIL set, keep doing that
> +	 * to not degrade callers.
>  	 */
>  	*gfp_cc_mask = (gfp_mask & (reclaim_mask | cc_action_mask)) |
> -			__GFP_HARDWALL | __GFP_MOVABLE | __GFP_RETRY_MAYFAIL;
> +			__GFP_MOVABLE | __GFP_RETRY_MAYFAIL;
>  	return 0;
>  }
>  

[PATCH RESEND v1 2/2] mm/memory_hotplug: don't use __GFP_HARDWALL when migrating pages via memory offlining

[David Hildenbrand]

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(-)

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;
-- 
2.47.1

Re: [PATCH RESEND v1 2/2] mm/memory_hotplug: don't use __GFP_HARDWALL when migrating pages via memory offlining

[Vlastimil Babka]

On 12/5/24 10:05, 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>

Reviewed-by: Vlastimil Babka <vbabka@suse.cz>

Thanks!

> ---
>  mm/memory_hotplug.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> 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;

Re: [PATCH RESEND v1 0/2] mm: don't use __GFP_HARDWALL when migrating remote pages

[Oscar Salvador]

On Thu, Dec 05, 2024 at 10:05:06AM +0100, David Hildenbrand wrote:
> Resending via a known-working SMTP setup.
> 
> ---
> 
> __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.

After the insight we gained from yesterday's discussion, this makes a
lot of sense, and I suspect this was one of those "that code makes it
that way, let's copy it just in case".
I will go through the patches later today and give me ack.

As you mentioned, migration code could potentially derive the policy
of the old pages and try to respect that when __HARDWALL.

It might not be possible though, but I guess it is a worth a shot.
I will try to investigate and see whether that is feasible.


-- 
Oscar Salvador
SUSE Labs