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))
next prev 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 page type is 0, migratetype passed is 2 (nr=256) 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.