From: mgorman@techsingularity.net (Mel Gorman)
To: linux-arm-kernel@lists.infradead.org
Subject: [BUG] Page allocation failures with newest kernels
Date: Thu, 2 Jun 2016 14:52:26 +0100 [thread overview]
Message-ID: <20160602135226.GX2527@techsingularity.net> (raw)
In-Reply-To: <CAPv3WKftqsEXbdU-geAcUKXBSskhA0V72N61a1a+5DfahLK_Dg@mail.gmail.com>
On Thu, Jun 02, 2016 at 07:48:38AM +0200, Marcin Wojtas wrote:
> Hi Will,
>
> I think I found a right trace. Following one-liner fixes the issue
> beginning from v4.2-rc1 up to v4.4 included:
>
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -294,7 +294,7 @@ static inline bool
> early_page_uninitialised(unsigned long pfn)
>
> static inline bool early_page_nid_uninitialised(unsigned long pfn, int nid)
> {
> - return false;
> + return true;
> }
>
How does that make a difference in v4.4 since commit
974a786e63c96a2401a78ddba926f34c128474f1 removed the only
early_page_nid_uninitialised() ? It further doesn't make sense if deferred
memory initialisation is not enabled as the pages will always be
initialised.
> From what I understood, now order-0 allocation keep no reserve at all.
Watermarks should still be preserved. zone_watermark_ok is still there.
What might change is the size of reserves for high-order atomic
allocations only. Fragmentation shouldn't be a factor. I'm missing some
major part of the picture.
--
Mel Gorman
SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mgorman@techsingularity.net>
To: Marcin Wojtas <mw@semihalf.com>
Cc: "Will Deacon" <will.deacon@arm.com>,
"Yehuda Yitschak" <yehuday@marvell.com>,
"Robin Murphy" <robin.murphy@arm.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"Lior Amsalem" <alior@marvell.com>,
"Thomas Petazzoni" <thomas.petazzoni@free-electrons.com>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Arnd Bergmann" <arnd@arndb.de>,
"Grzegorz Jaszczyk" <jaz@semihalf.com>,
"Nadav Haklai" <nadavh@marvell.com>,
"Tomasz Nowicki" <tn@semihalf.com>,
"Gregory Clément" <gregory.clement@free-electrons.com>
Subject: Re: [BUG] Page allocation failures with newest kernels
Date: Thu, 2 Jun 2016 14:52:26 +0100 [thread overview]
Message-ID: <20160602135226.GX2527@techsingularity.net> (raw)
In-Reply-To: <CAPv3WKftqsEXbdU-geAcUKXBSskhA0V72N61a1a+5DfahLK_Dg@mail.gmail.com>
On Thu, Jun 02, 2016 at 07:48:38AM +0200, Marcin Wojtas wrote:
> Hi Will,
>
> I think I found a right trace. Following one-liner fixes the issue
> beginning from v4.2-rc1 up to v4.4 included:
>
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -294,7 +294,7 @@ static inline bool
> early_page_uninitialised(unsigned long pfn)
>
> static inline bool early_page_nid_uninitialised(unsigned long pfn, int nid)
> {
> - return false;
> + return true;
> }
>
How does that make a difference in v4.4 since commit
974a786e63c96a2401a78ddba926f34c128474f1 removed the only
early_page_nid_uninitialised() ? It further doesn't make sense if deferred
memory initialisation is not enabled as the pages will always be
initialised.
> From what I understood, now order-0 allocation keep no reserve at all.
Watermarks should still be preserved. zone_watermark_ok is still there.
What might change is the size of reserves for high-order atomic
allocations only. Fragmentation shouldn't be a factor. I'm missing some
major part of the picture.
--
Mel Gorman
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mgorman@techsingularity.net>
To: Marcin Wojtas <mw@semihalf.com>
Cc: "Will Deacon" <will.deacon@arm.com>,
"Yehuda Yitschak" <yehuday@marvell.com>,
"Robin Murphy" <robin.murphy@arm.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"Lior Amsalem" <alior@marvell.com>,
"Thomas Petazzoni" <thomas.petazzoni@free-electrons.com>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Arnd Bergmann" <arnd@arndb.de>,
"Grzegorz Jaszczyk" <jaz@semihalf.com>,
"Nadav Haklai" <nadavh@marvell.com>,
"Tomasz Nowicki" <tn@semihalf.com>,
"Gregory Clément" <gregory.clement@free-electrons.com>
Subject: Re: [BUG] Page allocation failures with newest kernels
Date: Thu, 2 Jun 2016 14:52:26 +0100 [thread overview]
Message-ID: <20160602135226.GX2527@techsingularity.net> (raw)
In-Reply-To: <CAPv3WKftqsEXbdU-geAcUKXBSskhA0V72N61a1a+5DfahLK_Dg@mail.gmail.com>
On Thu, Jun 02, 2016 at 07:48:38AM +0200, Marcin Wojtas wrote:
> Hi Will,
>
> I think I found a right trace. Following one-liner fixes the issue
> beginning from v4.2-rc1 up to v4.4 included:
>
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -294,7 +294,7 @@ static inline bool
> early_page_uninitialised(unsigned long pfn)
>
> static inline bool early_page_nid_uninitialised(unsigned long pfn, int nid)
> {
> - return false;
> + return true;
> }
>
How does that make a difference in v4.4 since commit
974a786e63c96a2401a78ddba926f34c128474f1 removed the only
early_page_nid_uninitialised() ? It further doesn't make sense if deferred
memory initialisation is not enabled as the pages will always be
initialised.
> From what I understood, now order-0 allocation keep no reserve at all.
Watermarks should still be preserved. zone_watermark_ok is still there.
What might change is the size of reserves for high-order atomic
allocations only. Fragmentation shouldn't be a factor. I'm missing some
major part of the picture.
--
Mel Gorman
SUSE Labs
next prev parent reply other threads:[~2016-06-02 13:52 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-31 3:02 [BUG] Page allocation failures with newest kernels Marcin Wojtas
2016-05-31 3:02 ` Marcin Wojtas
2016-05-31 3:02 ` Marcin Wojtas
2016-05-31 10:17 ` Robin Murphy
2016-05-31 10:17 ` Robin Murphy
2016-05-31 10:17 ` Robin Murphy
2016-05-31 10:29 ` Marcin Wojtas
2016-05-31 10:29 ` Marcin Wojtas
2016-05-31 10:29 ` Marcin Wojtas
2016-05-31 13:10 ` Yehuda Yitschak
2016-05-31 13:10 ` Yehuda Yitschak
2016-05-31 13:10 ` Yehuda Yitschak
2016-05-31 13:15 ` Will Deacon
2016-05-31 13:15 ` Will Deacon
2016-05-31 13:15 ` Will Deacon
2016-06-02 5:48 ` Marcin Wojtas
2016-06-02 5:48 ` Marcin Wojtas
2016-06-02 5:48 ` Marcin Wojtas
2016-06-02 13:52 ` Mel Gorman [this message]
2016-06-02 13:52 ` Mel Gorman
2016-06-02 13:52 ` Mel Gorman
2016-06-02 19:01 ` Marcin Wojtas
2016-06-02 19:01 ` Marcin Wojtas
2016-06-02 19:01 ` Marcin Wojtas
2016-06-03 9:53 ` Mel Gorman
2016-06-03 9:53 ` Mel Gorman
2016-06-03 9:53 ` Mel Gorman
2016-06-03 11:57 ` Marcin Wojtas
2016-06-03 11:57 ` Marcin Wojtas
2016-06-03 11:57 ` Marcin Wojtas
2016-06-03 12:36 ` Mel Gorman
2016-06-03 12:36 ` Mel Gorman
2016-06-03 12:36 ` Mel Gorman
2016-06-07 17:36 ` Marcin Wojtas
2016-06-07 17:36 ` Marcin Wojtas
2016-06-07 17:36 ` Marcin Wojtas
2016-06-08 10:09 ` Mel Gorman
2016-06-08 10:09 ` Mel Gorman
2016-06-08 10:09 ` Mel Gorman
2016-06-09 18:13 ` Marcin Wojtas
2016-06-09 18:13 ` Marcin Wojtas
2016-06-09 18:13 ` Marcin Wojtas
2016-06-10 16:08 ` Marcin Wojtas
2016-06-10 16:08 ` Marcin Wojtas
2016-06-10 16:08 ` Marcin Wojtas
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=20160602135226.GX2527@techsingularity.net \
--to=mgorman@techsingularity.net \
--cc=linux-arm-kernel@lists.infradead.org \
/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.