From: Mel Gorman <mgorman@techsingularity.net>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: David Rientjes <rientjes@google.com>,
Vlastimil Babka <vbabka@suse.cz>,
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [patch] mm, page_alloc: move_freepages should not examine struct page of reserved memory
Date: Mon, 19 Aug 2019 14:35:41 +0100 [thread overview]
Message-ID: <20190819133541.GP2739@techsingularity.net> (raw)
In-Reply-To: <20190814154929.f050d937f2bd2c4d80c7f772@linux-foundation.org>
On Wed, Aug 14, 2019 at 03:49:29PM -0700, Andrew Morton wrote:
> On Tue, 13 Aug 2019 16:31:35 -0700 (PDT) David Rientjes <rientjes@google.com> wrote:
>
> > > > Move the debug checks to after verifying PageBuddy is true. This isolates
> > > > the scope of the checks to only be for buddy pages which are on the zone's
> > > > freelist which move_freepages_block() is operating on. In this case, an
> > > > incorrect node or zone is a bug worthy of being warned about (and the
> > > > examination of struct page is acceptable bcause this memory is not
> > > > reserved).
> > >
> > > I'm thinking Fixes:907ec5fca3dc and Cc:stable? But 907ec5fca3dc is
> > > almost a year old, so you were doing something special to trigger this?
> > >
> >
> > We noticed it almost immediately after bringing 907ec5fca3dc in on
> > CONFIG_DEBUG_VM builds. It depends on finding specific free pages in the
> > per-zone free area where the math in move_freepages() will bring the start
> > or end pfn into reserved memory and wanting to claim that entire pageblock
> > as a new migratetype. So the path will be rare, require CONFIG_DEBUG_VM,
> > and require fallback to a different migratetype.
> >
> > Some struct pages were already zeroed from reserve pages before
> > 907ec5fca3c so it theoretically could trigger before this commit. I think
> > it's rare enough under a config option that most people don't run that
> > others may not have noticed. I wouldn't argue against a stable tag and
> > the backport should be easy enough, but probably wouldn't single out a
> > commit that this is fixing.
>
> OK, thanks. I added the above two paragraphs to the changelog and
> removed the Fixes:
>
> Hopefully Mel will be able to review this for us.
Bit late as I was offline but FWIW
Acked-by: Mel Gorman <mgorman@techsingularity.net>
That said, the overhead of the debugging check is higher with this
patch although it'll only affect debug builds and the path is not
particularly hot. If this was a concern, I think it would be reasonable
to simply remove the debugging check as the zone boundaries are checked
in move_freepages_block and we never expect a zone/node to be smaller
than a pageblock and stuck in the middle of another zone.
--
Mel Gorman
SUSE Labs
prev parent reply other threads:[~2019-08-19 13:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-13 3:37 [patch] mm, page_alloc: move_freepages should not examine struct page of reserved memory David Rientjes
2019-08-13 13:03 ` Vlastimil Babka
2019-08-13 17:22 ` David Rientjes
2019-08-14 7:42 ` Vlastimil Babka
2019-08-13 21:16 ` Andrew Morton
2019-08-13 23:31 ` David Rientjes
2019-08-14 22:49 ` Andrew Morton
2019-08-19 13:35 ` Mel Gorman [this message]
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=20190819133541.GP2739@techsingularity.net \
--to=mgorman@techsingularity.net \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=rientjes@google.com \
--cc=vbabka@suse.cz \
/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.