From: Oscar Salvador <osalvador@suse.de>
To: David Hildenbrand <david@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>, Zi Yan <ziy@nvidia.com>
Subject: Re: [PATCH RESEND v1 0/2] mm: don't use __GFP_HARDWALL when migrating remote pages
Date: Thu, 5 Dec 2024 10:16:44 +0100 [thread overview]
Message-ID: <Z1FvfEwhvaZGJm7-@localhost.localdomain> (raw)
In-Reply-To: <20241205090508.2095225-1-david@redhat.com>
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
prev parent reply other threads:[~2024-12-05 9:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-05 9:05 David Hildenbrand
2024-12-05 9:05 ` [PATCH RESEND v1 1/2] mm/page_alloc: don't use __GFP_HARDWALL when migrating pages via alloc_contig*() David Hildenbrand
2024-12-09 17:45 ` Vlastimil Babka
2024-12-05 9:05 ` [PATCH RESEND v1 2/2] mm/memory_hotplug: don't use __GFP_HARDWALL when migrating pages via memory offlining David Hildenbrand
2024-12-09 17:47 ` Vlastimil Babka
2024-12-05 9:16 ` Oscar Salvador [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z1FvfEwhvaZGJm7-@localhost.localdomain \
--to=osalvador@suse.de \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=vbabka@suse.cz \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox