From: mgorman@techsingularity.net (Mel Gorman)
To: linux-arm-kernel@lists.infradead.org
Subject: [BUG] Page allocation failures with newest kernels
Date: Wed, 8 Jun 2016 11:09:51 +0100 [thread overview]
Message-ID: <20160608100950.GH2527@techsingularity.net> (raw)
In-Reply-To: <CAPv3WKfEQCeR++uqaUVhhsNe0WFsKq1Sn9uo==9NxtQe=GV7zw@mail.gmail.com>
On Tue, Jun 07, 2016 at 07:36:57PM +0200, Marcin Wojtas wrote:
> Hi Mel,
>
>
>
> 2016-06-03 14:36 GMT+02:00 Mel Gorman <mgorman@techsingularity.net>:
> > On Fri, Jun 03, 2016 at 01:57:06PM +0200, Marcin Wojtas wrote:
> >> >> For the record: the newest kernel I was able to reproduce the dumps
> >> >> was v4.6: http://pastebin.com/ekDdACn5. I've just checked v4.7-rc1,
> >> >> which comprise a lot (mainly yours) changes in mm, and I'm wondering
> >> >> if there may be a spot fix or rather a series of improvements. I'm
> >> >> looking forward to your opinion and would be grateful for any advice.
> >> >>
> >> >
> >> > I don't believe we want to reintroduce the reserve to cope with CMA. One
> >> > option would be to widen the gap between low and min watermark by the
> >> > size of the CMA region. The effect would be to wake kswapd earlier which
> >> > matters considering the context of the failing allocation was
> >> > GFP_ATOMIC.
> >>
> >> Of course my intention is not reintroducing anything that's gone
> >> forever, but just to find out way to overcome current issues. Do you
> >> mean increasing CMA size?
> >
> > No. There is a gap between the low and min watermarks. At the low point,
> > kswapd is woken up and at the min point allocation requests either
> > either direct reclaim or fail if they are atomic. What I'm suggesting
> > is that you adjust the low watermark and add the size of the CMA area
> > to it so that kswapd is woken earlier. The watermarks are calculated in
> > __setup_per_zone_wmarks
> >
>
> I printed all zones' settings, whose watermarks are configured within
> __setup_per_zone_wmarks(). There are three DMA, Normal and Movable -
> only first one's watermarks have non-zero values. Increasing DMA min
> watermark didn't help. I also played with increasing
Patch?
Did you establish why GFP_ATOMIC (assuming that's the failing site) had
not specified __GFP_ATOMIC at the time of the allocation failure?
--
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: Wed, 8 Jun 2016 11:09:51 +0100 [thread overview]
Message-ID: <20160608100950.GH2527@techsingularity.net> (raw)
In-Reply-To: <CAPv3WKfEQCeR++uqaUVhhsNe0WFsKq1Sn9uo==9NxtQe=GV7zw@mail.gmail.com>
On Tue, Jun 07, 2016 at 07:36:57PM +0200, Marcin Wojtas wrote:
> Hi Mel,
>
>
>
> 2016-06-03 14:36 GMT+02:00 Mel Gorman <mgorman@techsingularity.net>:
> > On Fri, Jun 03, 2016 at 01:57:06PM +0200, Marcin Wojtas wrote:
> >> >> For the record: the newest kernel I was able to reproduce the dumps
> >> >> was v4.6: http://pastebin.com/ekDdACn5. I've just checked v4.7-rc1,
> >> >> which comprise a lot (mainly yours) changes in mm, and I'm wondering
> >> >> if there may be a spot fix or rather a series of improvements. I'm
> >> >> looking forward to your opinion and would be grateful for any advice.
> >> >>
> >> >
> >> > I don't believe we want to reintroduce the reserve to cope with CMA. One
> >> > option would be to widen the gap between low and min watermark by the
> >> > size of the CMA region. The effect would be to wake kswapd earlier which
> >> > matters considering the context of the failing allocation was
> >> > GFP_ATOMIC.
> >>
> >> Of course my intention is not reintroducing anything that's gone
> >> forever, but just to find out way to overcome current issues. Do you
> >> mean increasing CMA size?
> >
> > No. There is a gap between the low and min watermarks. At the low point,
> > kswapd is woken up and at the min point allocation requests either
> > either direct reclaim or fail if they are atomic. What I'm suggesting
> > is that you adjust the low watermark and add the size of the CMA area
> > to it so that kswapd is woken earlier. The watermarks are calculated in
> > __setup_per_zone_wmarks
> >
>
> I printed all zones' settings, whose watermarks are configured within
> __setup_per_zone_wmarks(). There are three DMA, Normal and Movable -
> only first one's watermarks have non-zero values. Increasing DMA min
> watermark didn't help. I also played with increasing
Patch?
Did you establish why GFP_ATOMIC (assuming that's the failing site) had
not specified __GFP_ATOMIC at the time of the allocation failure?
--
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: Wed, 8 Jun 2016 11:09:51 +0100 [thread overview]
Message-ID: <20160608100950.GH2527@techsingularity.net> (raw)
In-Reply-To: <CAPv3WKfEQCeR++uqaUVhhsNe0WFsKq1Sn9uo==9NxtQe=GV7zw@mail.gmail.com>
On Tue, Jun 07, 2016 at 07:36:57PM +0200, Marcin Wojtas wrote:
> Hi Mel,
>
>
>
> 2016-06-03 14:36 GMT+02:00 Mel Gorman <mgorman@techsingularity.net>:
> > On Fri, Jun 03, 2016 at 01:57:06PM +0200, Marcin Wojtas wrote:
> >> >> For the record: the newest kernel I was able to reproduce the dumps
> >> >> was v4.6: http://pastebin.com/ekDdACn5. I've just checked v4.7-rc1,
> >> >> which comprise a lot (mainly yours) changes in mm, and I'm wondering
> >> >> if there may be a spot fix or rather a series of improvements. I'm
> >> >> looking forward to your opinion and would be grateful for any advice.
> >> >>
> >> >
> >> > I don't believe we want to reintroduce the reserve to cope with CMA. One
> >> > option would be to widen the gap between low and min watermark by the
> >> > size of the CMA region. The effect would be to wake kswapd earlier which
> >> > matters considering the context of the failing allocation was
> >> > GFP_ATOMIC.
> >>
> >> Of course my intention is not reintroducing anything that's gone
> >> forever, but just to find out way to overcome current issues. Do you
> >> mean increasing CMA size?
> >
> > No. There is a gap between the low and min watermarks. At the low point,
> > kswapd is woken up and at the min point allocation requests either
> > either direct reclaim or fail if they are atomic. What I'm suggesting
> > is that you adjust the low watermark and add the size of the CMA area
> > to it so that kswapd is woken earlier. The watermarks are calculated in
> > __setup_per_zone_wmarks
> >
>
> I printed all zones' settings, whose watermarks are configured within
> __setup_per_zone_wmarks(). There are three DMA, Normal and Movable -
> only first one's watermarks have non-zero values. Increasing DMA min
> watermark didn't help. I also played with increasing
Patch?
Did you establish why GFP_ATOMIC (assuming that's the failing site) had
not specified __GFP_ATOMIC at the time of the allocation failure?
--
Mel Gorman
SUSE Labs
next prev parent reply other threads:[~2016-06-08 10:09 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
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 [this message]
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=20160608100950.GH2527@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.