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

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