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

From: Oscar Salvador
Date: Thu Dec 05 2024 - 04:17:02 EST


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