linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Gordeev <agordeev@linux.ibm.com>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Zi Yan <ziy@nvidia.com>,
	Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
	Marc Hartmayer <mhartmay@linux.ibm.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Baolin Wang <baolin.wang@linux.alibaba.com>,
	linux-mm@kvack.org, linux-s390@vger.kernel.org,
	Heiko Carstens <hca@linux.ibm.com>
Subject: Re: page type is 0, migratetype passed is 2 (nr=256)
Date: Mon, 10 Nov 2025 15:39:11 +0100	[thread overview]
Message-ID: <20251110143911.1716086Add-agordeev@linux.ibm.com> (raw)
In-Reply-To: <20250512171429.GB615800@cmpxchg.org>

On Mon, May 12, 2025 at 01:14:29PM -0400, Johannes Weiner wrote:

Hi Johannes,

> On Mon, May 12, 2025 at 12:35:39PM -0400, Zi Yan wrote:
> > On 12 May 2025, at 12:16, Lorenzo Stoakes wrote:
> > 
> > > +cc Zi
> > >
> > > Hi Marc,
> > >
> > > I noticed this same bug as reported in [0], but only for a _very_ recent
> > > patch series by Zi, which is only present in mm-new, which is the most
> > > unstable mm branch right now :)
> > >
> > > So I wonder if related or a coincidence caused by something else?
> > 
> > Unless Marc's branch has my "make MIGRATE_ISOLATE a standalone bit" patchset,
> > it should be caused by something else.
> > 
> > A bisect would be very helpful.
> > 
> > >
> > > This is triggered by the mm self-test (in tools/testing/selftests/mm, you
> > > can just make -jXX there) transhuge-stress, invoked as:
> > >
> > > $ sudo ./transhuge-stress -d 20
> > >
> > > The stack traces do look very different though so perhaps unrelated?
> > 
> > The warning is triggered, in the both cases, a pageblock with MIGRATE_UNMOVABLE(0)
> > is moved to MIGRATE_RECLAIMABLE(2). The pageblock is supposed to have
> > MIGRATE_RECLAIMABLE(2) before the movement.
> 
> The weird thing is that the warning is from expand(), when the broken
> up chunks are put *back*. Marc, can you confirm that this is the only
> warning in dmesg, and there aren't any before this one?
> 
> The request does the following:
> 
>   rmqueue_bulk()
>     __rmqueue()
>       __rmqueue_smallest()
>         page_del_and_expand()
>           __del_page_from_free_list()
>             VM_WARN_ONCE(get_pageblock_migratetype(page) != migratetype,
>                          "page type is %lu, passed migratetype is %d (nr=%d)\n",
>                          get_pageblock_migratetype(page), migratetype, nr_pages);
>          expand()
>            __add_to_free_list()
>              VM_WARN_ONCE(get_pageblock_migratetype(page) != migratetype,
>                           "page type is %lu, passed migratetype is %d (nr=%d)\n",
>                           get_pageblock_migratetype(page), migratetype, nr_pages);
> 
> So if only the second one triggers, but not the first one, it suggests
> we have a buddy page consisting of two pageblocks of different types -
> the first one reclaimable and the second unmovable. When we take the
> headpage off, the type matches. When we put the remainder from the
> tailblock back, it doesn't.

With some extra debugging added on top of 6.18-rc3 we see this:

[  388.664966] +++ __add_to_free_list(814) type 0, migratetype 1 order 8 nr 256 pid 3917 comm mempig_verify
[  388.665533] +++ __del_page_from_free_list(868) type 0, migratetype 1 order 8 nr 256 pid 3917 comm mempig_verify

Does it make sense?

Thanks!

FWIW here is the patch:

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 600d9e981c23..82b171af5b4d 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -806,12 +806,15 @@ static inline void __add_to_free_list(struct page *page, struct zone *zone,
 				      unsigned int order, int migratetype,
 				      bool tail)
 {
+	enum migratetype pagetype = get_pageblock_migratetype(page);
 	struct free_area *area = &zone->free_area[order];
 	int nr_pages = 1 << order;
 
-	VM_WARN_ONCE(get_pageblock_migratetype(page) != migratetype,
-		     "page type is %d, passed migratetype is %d (nr=%d)\n",
-		     get_pageblock_migratetype(page), migratetype, nr_pages);
+        if (pagetype != migratetype) {
+		pr_warn("+++ %s(%d) type %d, migratetype %d order %d nr %d pid %d comm %s\n",
+			__FUNCTION__, __LINE__,
+			pagetype, migratetype, order, nr_pages, current->pid, current->comm);
+	}
 
 	if (tail)
 		list_add_tail(&page->buddy_list, &area->free_list[migratetype]);
@@ -831,13 +834,16 @@ static inline void __add_to_free_list(struct page *page, struct zone *zone,
 static inline void move_to_free_list(struct page *page, struct zone *zone,
 				     unsigned int order, int old_mt, int new_mt)
 {
+	enum migratetype pagetype = get_pageblock_migratetype(page);
 	struct free_area *area = &zone->free_area[order];
 	int nr_pages = 1 << order;
 
 	/* Free page moving can fail, so it happens before the type update */
-	VM_WARN_ONCE(get_pageblock_migratetype(page) != old_mt,
-		     "page type is %d, passed migratetype is %d (nr=%d)\n",
-		     get_pageblock_migratetype(page), old_mt, nr_pages);
+        if (pagetype != old_mt) {
+		pr_warn("+++ %s(%d) type %d, migratetype %d order %d nr %d pid %d comm %s\n",
+			__FUNCTION__, __LINE__,
+			pagetype, old_mt, order, nr_pages, current->pid, current->comm);
+	}
 
 	list_move_tail(&page->buddy_list, &area->free_list[new_mt]);
 
@@ -855,11 +861,14 @@ static inline void move_to_free_list(struct page *page, struct zone *zone,
 static inline void __del_page_from_free_list(struct page *page, struct zone *zone,
 					     unsigned int order, int migratetype)
 {
+	enum migratetype pagetype = get_pageblock_migratetype(page);
 	int nr_pages = 1 << order;
 
-        VM_WARN_ONCE(get_pageblock_migratetype(page) != migratetype,
-		     "page type is %d, passed migratetype is %d (nr=%d)\n",
-		     get_pageblock_migratetype(page), migratetype, nr_pages);
+        if (pagetype != migratetype) {
+		pr_warn("+++ %s(%d) type %d, migratetype %d order %d nr %d pid %d comm %s\n",
+			__FUNCTION__, __LINE__,
+			pagetype, migratetype, order, nr_pages, current->pid, current->comm);
+	}
 
 	/* clear reported state and update reported page count */
 	if (page_reported(page))


  parent reply	other threads:[~2025-11-10 14:39 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-12 14:18 Marc Hartmayer
2025-05-12 16:16 ` Lorenzo Stoakes
2025-05-12 16:35   ` Zi Yan
2025-05-12 17:14     ` Johannes Weiner
2025-05-20 10:23       ` Marc Hartmayer
2025-06-12  9:05         ` Alexander Gordeev
2025-06-14  8:24           ` Johannes Weiner
2025-08-05 12:02             ` Alexander Gordeev
2025-11-10 14:39       ` Alexander Gordeev [this message]
2025-05-13  8:30   ` Marc Hartmayer

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=20251110143911.1716086Add-agordeev@linux.ibm.com \
    --to=agordeev@linux.ibm.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=hannes@cmpxchg.org \
    --cc=hca@linux.ibm.com \
    --cc=linux-mm@kvack.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=mhartmay@linux.ibm.com \
    --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