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