All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.