[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241205085217.2086353-1-david@redhat.com>
Date: Thu, 5 Dec 2024 09:52:15 +0100
From: David Hildenbrand <david@...hat.com>
To: linux-kernel@...r.kernel.org
Cc: linux-mm@...ck.org,
David Hildenbrand <david@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Vlastimil Babka <vbabka@...e.cz>,
Oscar Salvador <osalvador@...e.de>,
Zi Yan <ziy@...dia.com>
Subject: [PATCH v1 0/2] mm: don't use __GFP_HARDWALL when migrating remote pages
Sending this via the RH SMTP first, because IT doesn't see any obvious
problems why the mails shouldn't be reaching linux-mm, so let's see if
the problems are gone now. If this doesn't work, I'll resend them
using the known-working gmail SMTP. Sorry already for the noise ...
---
__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@...ux-foundation.org>
Cc: Vlastimil Babka <vbabka@...e.cz>
Cc: Oscar Salvador <osalvador@...e.de>
Cc: Zi Yan <ziy@...dia.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
Powered by blists - more mailing lists