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

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

[David Hildenbrand]

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@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 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

[PATCH 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

linux-mm mailing list problems

[David Hildenbrand]

On 05.12.24 09:52, David Hildenbrand wrote:
> 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 ...

I talked to RH IT, and it looks like the mails get delivered to 
linux-mm@kvack.org just fine, and linux-mm decides to silently drop them.

Does anybody know who maintains linux-mm@kvack.org? I wrote a mail to 
mbot@kvack.org, but I am pretty sure that is the wrong address.

-- 
Cheers,

David / dhildenb

Re: linux-mm mailing list problems

[Vlastimil Babka]

On 12/5/24 13:12, David Hildenbrand wrote:
> On 05.12.24 09:52, David Hildenbrand wrote:
>> 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 ...
> 
> I talked to RH IT, and it looks like the mails get delivered to 
> linux-mm@kvack.org just fine, and linux-mm decides to silently drop them.
> 
> Does anybody know who maintains linux-mm@kvack.org? I wrote a mail to 
> mbot@kvack.org, but I am pretty sure that is the wrong address.

AFAIK it's Benjamin, CC'd

Re: linux-mm mailing list problems

[Benjamin LaHaise]

On Thu, Dec 05, 2024 at 03:43:54PM +0100, Vlastimil Babka wrote:
> On 12/5/24 13:12, David Hildenbrand wrote:
> > On 05.12.24 09:52, David Hildenbrand wrote:
> >> 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 ...
> > 
> > I talked to RH IT, and it looks like the mails get delivered to 
> > linux-mm@kvack.org just fine, and linux-mm decides to silently drop them.

Messages were being dumped into a spam folder as the upstream spam
filtering service used for kvack.org was incorrectly tagging them as spam.
The folder where these messages were being quarantined in was not the one
being checked for the last few months due to the spam tagging changing
back on September 8th.

> > Does anybody know who maintains linux-mm@kvack.org?

Use owner-linux-mm@kvack.org, which has been in place since the mailing
list was first created.  That is the sender of every mailing list message.

Unfortunately, the issue was not flagged to me until today.  The mailing
list footers that used to let people know about the mailing list contact
info previously had to be removed due to the implementation of DKIM
enforcement.  Even sending emails to majordomo@ per the List-Subscribe:
and List-Unsubscribe: headers would have gotten my attention.

> > I wrote a mail to 
> > mbot@kvack.org, but I am pretty sure that is the wrong address.

mbot@kvack.org is a spam trap.  Do not send emails there unless you want
to be marked as a spam sender.

> AFAIK it's Benjamin, CC'd

It should now be fixed as I have tweaked the spam filtering rules.  The
messages misfiled as spam since September 8th have now been delivered.
I'm shocked that nobody bothered reporting this until now.  Please do not
report mailing list issues to the mailing list.  I simply do not have the
time / energy to scan the thousands of messages that fly by every week.
Cheers,

		-ben
-- 
"Thought is the essence of where you are now."

Re: linux-mm mailing list problems

[David Hildenbrand]

On 05.12.24 16:42, Benjamin LaHaise wrote:
> On Thu, Dec 05, 2024 at 03:43:54PM +0100, Vlastimil Babka wrote:
>> On 12/5/24 13:12, David Hildenbrand wrote:
>>> On 05.12.24 09:52, David Hildenbrand wrote:
>>>> 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 ...
>>>
>>> I talked to RH IT, and it looks like the mails get delivered to
>>> linux-mm@kvack.org just fine, and linux-mm decides to silently drop them.
> 
> Messages were being dumped into a spam folder as the upstream spam
> filtering service used for kvack.org was incorrectly tagging them as spam.
> The folder where these messages were being quarantined in was not the one
> being checked for the last few months due to the spam tagging changing
> back on September 8th.

Ah that explains it,

> 
>>> Does anybody know who maintains linux-mm@kvack.org?
> 
> Use owner-linux-mm@kvack.org, which has been in place since the mailing
> list was first created.  That is the sender of every mailing list message.

Ah!

> 
> Unfortunately, the issue was not flagged to me until today.  The mailing
> list footers that used to let people know about the mailing list contact
> info previously had to be removed due to the implementation of DKIM
> enforcement.  Even sending emails to majordomo@ per the List-Subscribe:
> and List-Unsubscribe: headers would have gotten my attention.

Yeah, I tried hard finding a contact, and apparently ...

> 
>>> I wrote a mail to
>>> mbot@kvack.org, but I am pretty sure that is the wrong address.
> 
> mbot@kvack.org is a spam trap.  Do not send emails there unless you want
> to be marked as a spam sender.

... all I found was a trap :)

(guess I'm now a swam sender ;) )

> 
>> AFAIK it's Benjamin, CC'd
> 
> It should now be fixed as I have tweaked the spam filtering rules. 

Thanks!

> The
> messages misfiled as spam since September 8th have now been delivered.
> I'm shocked that nobody bothered reporting this until now.  

Hm, I sent quite a bunch of patches after September 8th, and I think 
they mostly got delivered. For me, it started ~1 week ago.


> Please do not
> report mailing list issues to the mailing list.  I simply do not have the
> time / energy to scan the thousands of messages that fly by every week.

Now that I know how to contact you, that will obviously be my first choice.

Thanks!

-- 
Cheers,

David / dhildenb

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

[Oscar Salvador]

On Thu, Dec 05, 2024 at 09:52:16AM +0100, 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: Oscar Salvador <osalvador@suse.de>


-- 
Oscar Salvador
SUSE Labs

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

[Oscar Salvador]

On Thu, Dec 05, 2024 at 09:52:17AM +0100, 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>

Acked-by: Oscar Salvador <osalvador@suse.de>


-- 
Oscar Salvador
SUSE Labs