From: Minchan Kim <minchan.kim@gmail.com>
To: Andrew Lutomirski <luto@mit.edu>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
fengguang.wu@intel.com, andi@firstfloor.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, mgorman@suse.de,
hannes@cmpxchg.org, riel@redhat.com
Subject: Re: Kernel falls apart under light memory pressure (i.e. linking vmlinux)
Date: Sat, 21 May 2011 00:33:46 +0900 [thread overview]
Message-ID: <20110520153346.GA1843@barrios-desktop> (raw)
In-Reply-To: <BANLkTikAFMvpgHR2dopd+Nvjfyw_XT5=LA@mail.gmail.com>
On Fri, May 20, 2011 at 10:11:47AM -0400, Andrew Lutomirski wrote:
> On Fri, May 20, 2011 at 6:11 AM, Andrea Arcangeli <aarcange@redhat.com> wrote:
> > I figure it's not easily reproducible but you can easily rule out THP
> > issues by reproducing at least once after booting with
> > transparent_hugepage=never or by building the kernel with
> > CONFIG_TRANSPARENT_HUGEPAGE=n.
>
> Reproduced with CONFIG_TRANSPARENT_HUGEPAGE=n with and without
> compaction and migration.
>
> I applied the attached patch (which includes Minchan's !pgdat_balanced
> and need_resched changes). I see:
>
> [ 121.468339] firefox shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea00019217a8) w/ prev = 100000000002000D
> [ 121.469236] firefox shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea00016596b8) w/ prev = 100000000002000D
> [ 121.470207] firefox: shrink_page_list (nr_scanned=94
> nr_reclaimed=19 nr_to_reclaim=32 gfp_mask=201DA) found inactive page
> ffffea00019217a8 with flags=100000000002004D
> [ 121.472451] firefox: shrink_page_list (nr_scanned=94
> nr_reclaimed=19 nr_to_reclaim=32 gfp_mask=201DA) found inactive page
> ffffea00016596b8 with flags=100000000002004D
> [ 121.482782] dd shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea00013a8938) w/ prev = 100000000002000D
> [ 121.489820] dd shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea00017a4e88) w/ prev = 1000000000000801
> [ 121.490626] dd shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea000005edb0) w/ prev = 1000000000000801
> [ 121.491499] dd: shrink_page_list (nr_scanned=62 nr_reclaimed=0
> nr_to_reclaim=32 gfp_mask=200D2) found inactive page ffffea00017a4e88
> with flags=1000000000000841
> [ 121.494337] dd: shrink_page_list (nr_scanned=62 nr_reclaimed=0
> nr_to_reclaim=32 gfp_mask=200D2) found inactive page ffffea000005edb0
> with flags=1000000000000841
> [ 121.499219] dd shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea000129c788) w/ prev = 1000000000080009
> [ 121.500363] dd shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea000129c830) w/ prev = 1000000000080009
> [ 121.502270] kswapd0 shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea0001146470) w/ prev = 100000000008001D
> [ 121.661545] kworker/1:1 shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea0000058168) w/ prev = 1000000000000801
> [ 121.662791] kworker/1:1 shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea000166f288) w/ prev = 1000000000000801
> [ 121.665727] kworker/1:1 shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea0001681c40) w/ prev = 1000000000000801
> [ 121.666857] kworker/1:1 shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea0001693130) w/ prev = 1000000000000801
> [ 121.667988] kworker/1:1 shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea0000c790d8) w/ prev = 1000000000000801
> [ 121.669105] kworker/1:1 shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea000113fe48) w/ prev = 1000000000000801
> [ 121.670238] kworker/1:1: shrink_page_list (nr_scanned=102
> nr_reclaimed=20 nr_to_reclaim=32 gfp_mask=11212) found inactive page
> ffffea0000058168 with flags=1000000000000841
> [ 121.674061] kworker/1:1: shrink_page_list (nr_scanned=102
> nr_reclaimed=20 nr_to_reclaim=32 gfp_mask=11212) found inactive page
> ffffea000166f288 with flags=1000000000000841
> [ 121.678054] kworker/1:1: shrink_page_list (nr_scanned=102
> nr_reclaimed=20 nr_to_reclaim=32 gfp_mask=11212) found inactive page
> ffffea0001681c40 with flags=1000000000000841
> [ 121.682069] kworker/1:1: shrink_page_list (nr_scanned=102
> nr_reclaimed=20 nr_to_reclaim=32 gfp_mask=11212) found inactive page
> ffffea0001693130 with flags=1000000000000841
> [ 121.686074] kworker/1:1: shrink_page_list (nr_scanned=102
> nr_reclaimed=20 nr_to_reclaim=32 gfp_mask=11212) found inactive page
> ffffea0000c790d8 with flags=1000000000000841
> [ 121.690045] kworker/1:1: shrink_page_list (nr_scanned=102
> nr_reclaimed=20 nr_to_reclaim=32 gfp_mask=11212) found inactive page
> ffffea000113fe48 with flags=1000000000000841
> [ 121.866205] test_mempressur shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea000165d5b8) w/ prev = 100000000002000D
> [ 121.868204] test_mempressur shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea0001661288) w/ prev = 100000000002000D
> [ 121.870203] test_mempressur shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea0001661250) w/ prev = 100000000002000D
> [ 121.872195] test_mempressur shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea000100cee8) w/ prev = 100000000002000D
> [ 121.873486] test_mempressur shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea0000eafab8) w/ prev = 100000000002000D
> [ 121.874718] test_mempressur shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea0000eafaf0) w/ prev = 100000000002000D
>
> This is interesting: it looks like shrink_page_list is making its way
> through the list more than once. It could be reentering itself
> somehow or it could have something screwed up with the linked list.
>
> I'll keep slowly debugging, but maybe this is enough for someone
> familiar with this code to beat me to it.
>
> Minchan, I think this means that your fixes are just hiding and not
> fixing the underlying problem.
Could you test with below patch?
If this patch fixes it, I don't know why we see this problem now.
It should be problem long time ago.
>From b7d7ca54b3ed914723cc54d1c3bcd937e5f08e3a Mon Sep 17 00:00:00 2001
From: Minchan Kim <minchan.kim@gmail.com>
Date: Sat, 21 May 2011 00:28:00 +0900
Subject: [BUG fix] vmscan: Clear PageActive before synchronous shrink_page_list
Normally, shrink_page_list doesn't reclaim working set page(ie, PG_referenced).
So it should return active lru list
For it, shrink_page_list does SetPageActive for them.
Sometime, we can ignore that and try to reclaim them when we reclaim high-order pages
through consecutive second call of synchronous shrink_page_list.
At that time, the pages which have PG_active could be caught by VM_BUG_ON(PageActive(page))
in shrink_page_list.
This patch clears PG_active before entering synchronous shrink_page_list.
Reported-by: Andrew Lutomirski <luto@mit.edu>
Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
---
mm/vmscan.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 8bfd450..a5c01e9 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1430,7 +1430,10 @@ shrink_inactive_list(unsigned long nr_to_scan, struct zone *zone,
/* Check if we should syncronously wait for writeback */
if (should_reclaim_stall(nr_taken, nr_reclaimed, priority, sc)) {
+ unsigned long nr_active;
set_reclaim_mode(priority, sc, true);
+ nr_active = clear_active_flags(&page_list, NULL);
+ count_vm_events(PGDEACTIVATE, nr_active);
nr_reclaimed += shrink_page_list(&page_list, zone, sc);
}
--
1.7.1
--
Kind regards,
Minchan Kim
WARNING: multiple messages have this Message-ID (diff)
From: Minchan Kim <minchan.kim@gmail.com>
To: Andrew Lutomirski <luto@mit.edu>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
fengguang.wu@intel.com, andi@firstfloor.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, mgorman@suse.de,
hannes@cmpxchg.org, riel@redhat.com
Subject: Re: Kernel falls apart under light memory pressure (i.e. linking vmlinux)
Date: Sat, 21 May 2011 00:33:46 +0900 [thread overview]
Message-ID: <20110520153346.GA1843@barrios-desktop> (raw)
In-Reply-To: <BANLkTikAFMvpgHR2dopd+Nvjfyw_XT5=LA@mail.gmail.com>
On Fri, May 20, 2011 at 10:11:47AM -0400, Andrew Lutomirski wrote:
> On Fri, May 20, 2011 at 6:11 AM, Andrea Arcangeli <aarcange@redhat.com> wrote:
> > I figure it's not easily reproducible but you can easily rule out THP
> > issues by reproducing at least once after booting with
> > transparent_hugepage=never or by building the kernel with
> > CONFIG_TRANSPARENT_HUGEPAGE=n.
>
> Reproduced with CONFIG_TRANSPARENT_HUGEPAGE=n with and without
> compaction and migration.
>
> I applied the attached patch (which includes Minchan's !pgdat_balanced
> and need_resched changes). I see:
>
> [ 121.468339] firefox shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea00019217a8) w/ prev = 100000000002000D
> [ 121.469236] firefox shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea00016596b8) w/ prev = 100000000002000D
> [ 121.470207] firefox: shrink_page_list (nr_scanned=94
> nr_reclaimed=19 nr_to_reclaim=32 gfp_mask=201DA) found inactive page
> ffffea00019217a8 with flags=100000000002004D
> [ 121.472451] firefox: shrink_page_list (nr_scanned=94
> nr_reclaimed=19 nr_to_reclaim=32 gfp_mask=201DA) found inactive page
> ffffea00016596b8 with flags=100000000002004D
> [ 121.482782] dd shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea00013a8938) w/ prev = 100000000002000D
> [ 121.489820] dd shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea00017a4e88) w/ prev = 1000000000000801
> [ 121.490626] dd shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea000005edb0) w/ prev = 1000000000000801
> [ 121.491499] dd: shrink_page_list (nr_scanned=62 nr_reclaimed=0
> nr_to_reclaim=32 gfp_mask=200D2) found inactive page ffffea00017a4e88
> with flags=1000000000000841
> [ 121.494337] dd: shrink_page_list (nr_scanned=62 nr_reclaimed=0
> nr_to_reclaim=32 gfp_mask=200D2) found inactive page ffffea000005edb0
> with flags=1000000000000841
> [ 121.499219] dd shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea000129c788) w/ prev = 1000000000080009
> [ 121.500363] dd shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea000129c830) w/ prev = 1000000000080009
> [ 121.502270] kswapd0 shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea0001146470) w/ prev = 100000000008001D
> [ 121.661545] kworker/1:1 shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea0000058168) w/ prev = 1000000000000801
> [ 121.662791] kworker/1:1 shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea000166f288) w/ prev = 1000000000000801
> [ 121.665727] kworker/1:1 shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea0001681c40) w/ prev = 1000000000000801
> [ 121.666857] kworker/1:1 shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea0001693130) w/ prev = 1000000000000801
> [ 121.667988] kworker/1:1 shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea0000c790d8) w/ prev = 1000000000000801
> [ 121.669105] kworker/1:1 shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea000113fe48) w/ prev = 1000000000000801
> [ 121.670238] kworker/1:1: shrink_page_list (nr_scanned=102
> nr_reclaimed=20 nr_to_reclaim=32 gfp_mask=11212) found inactive page
> ffffea0000058168 with flags=1000000000000841
> [ 121.674061] kworker/1:1: shrink_page_list (nr_scanned=102
> nr_reclaimed=20 nr_to_reclaim=32 gfp_mask=11212) found inactive page
> ffffea000166f288 with flags=1000000000000841
> [ 121.678054] kworker/1:1: shrink_page_list (nr_scanned=102
> nr_reclaimed=20 nr_to_reclaim=32 gfp_mask=11212) found inactive page
> ffffea0001681c40 with flags=1000000000000841
> [ 121.682069] kworker/1:1: shrink_page_list (nr_scanned=102
> nr_reclaimed=20 nr_to_reclaim=32 gfp_mask=11212) found inactive page
> ffffea0001693130 with flags=1000000000000841
> [ 121.686074] kworker/1:1: shrink_page_list (nr_scanned=102
> nr_reclaimed=20 nr_to_reclaim=32 gfp_mask=11212) found inactive page
> ffffea0000c790d8 with flags=1000000000000841
> [ 121.690045] kworker/1:1: shrink_page_list (nr_scanned=102
> nr_reclaimed=20 nr_to_reclaim=32 gfp_mask=11212) found inactive page
> ffffea000113fe48 with flags=1000000000000841
> [ 121.866205] test_mempressur shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea000165d5b8) w/ prev = 100000000002000D
> [ 121.868204] test_mempressur shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea0001661288) w/ prev = 100000000002000D
> [ 121.870203] test_mempressur shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea0001661250) w/ prev = 100000000002000D
> [ 121.872195] test_mempressur shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea000100cee8) w/ prev = 100000000002000D
> [ 121.873486] test_mempressur shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea0000eafab8) w/ prev = 100000000002000D
> [ 121.874718] test_mempressur shrink_page_list+0x4f3/0x5ca:
> SetPageActive(ffffea0000eafaf0) w/ prev = 100000000002000D
>
> This is interesting: it looks like shrink_page_list is making its way
> through the list more than once. It could be reentering itself
> somehow or it could have something screwed up with the linked list.
>
> I'll keep slowly debugging, but maybe this is enough for someone
> familiar with this code to beat me to it.
>
> Minchan, I think this means that your fixes are just hiding and not
> fixing the underlying problem.
Could you test with below patch?
If this patch fixes it, I don't know why we see this problem now.
It should be problem long time ago.
next prev parent reply other threads:[~2011-05-20 15:33 UTC|newest]
Thread overview: 102+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-11 22:42 Kernel falls apart under light memory pressure (i.e. linking vmlinux) Andrew Lutomirski
2011-05-11 23:07 ` Andi Kleen
2011-05-11 23:28 ` Andrew Lutomirski
2011-05-12 5:46 ` Andi Kleen
2011-05-12 11:54 ` Andrew Lutomirski
2011-05-14 15:46 ` Andrew Lutomirski
2011-05-14 15:46 ` Andrew Lutomirski
2011-05-14 16:53 ` Andi Kleen
2011-05-14 16:53 ` Andi Kleen
[not found] ` <BANLkTik6SS9NH7XVSRBoCR16_5veY0MKBw@mail.gmail.com>
2011-05-14 17:43 ` Andi Kleen
2011-05-15 1:37 ` Minchan Kim
2011-05-15 15:27 ` Wu Fengguang
2011-05-15 15:27 ` Wu Fengguang
2011-05-15 15:59 ` Andrew Lutomirski
2011-05-15 15:59 ` Andrew Lutomirski
2011-05-15 22:58 ` Minchan Kim
2011-05-15 22:58 ` Minchan Kim
2011-05-16 8:51 ` Mel Gorman
2011-05-16 8:51 ` Mel Gorman
2011-05-15 16:12 ` Andrew Lutomirski
2011-05-15 16:12 ` Andrew Lutomirski
2011-05-17 6:00 ` Wu Fengguang
2011-05-17 6:00 ` Wu Fengguang
2011-05-17 6:35 ` Minchan Kim
2011-05-17 6:35 ` Minchan Kim
2011-05-17 19:22 ` Andrew Lutomirski
2011-05-18 5:17 ` Minchan Kim
2011-05-18 5:17 ` Minchan Kim
2011-05-19 2:15 ` Andrew Lutomirski
2011-05-19 2:30 ` KAMEZAWA Hiroyuki
2011-05-19 2:30 ` KAMEZAWA Hiroyuki
2011-05-19 2:41 ` Andrew Lutomirski
2011-05-19 2:54 ` Minchan Kim
2011-05-19 2:54 ` Minchan Kim
2011-05-19 14:16 ` Andrew Lutomirski
2011-05-20 0:17 ` Minchan Kim
2011-05-20 0:17 ` Minchan Kim
2011-05-20 2:58 ` Andrew Lutomirski
2011-05-20 2:58 ` Andrew Lutomirski
2011-05-20 3:12 ` KOSAKI Motohiro
2011-05-20 3:12 ` KOSAKI Motohiro
2011-05-20 3:38 ` Andrew Lutomirski
2011-05-20 3:38 ` Andrew Lutomirski
2011-05-20 4:20 ` Minchan Kim
2011-05-20 4:20 ` Minchan Kim
2011-05-20 5:08 ` KAMEZAWA Hiroyuki
2011-05-20 5:08 ` KAMEZAWA Hiroyuki
2011-05-20 5:36 ` Minchan Kim
2011-05-20 5:36 ` Minchan Kim
2011-05-20 7:43 ` KAMEZAWA Hiroyuki
2011-05-20 7:43 ` KAMEZAWA Hiroyuki
2011-05-20 10:11 ` Andrea Arcangeli
2011-05-20 10:11 ` Andrea Arcangeli
2011-05-20 14:11 ` Andrew Lutomirski
2011-05-20 15:33 ` Minchan Kim [this message]
2011-05-20 15:33 ` Minchan Kim
2011-05-20 16:01 ` Andrew Lutomirski
2011-05-20 16:01 ` Andrew Lutomirski
2011-05-20 16:19 ` Minchan Kim
2011-05-20 16:19 ` Minchan Kim
2011-05-20 18:09 ` Andrew Lutomirski
2011-05-20 18:40 ` Andrew Lutomirski
2011-05-20 18:40 ` Andrew Lutomirski
2011-05-21 12:04 ` KOSAKI Motohiro
2011-05-21 12:04 ` KOSAKI Motohiro
2011-05-21 13:34 ` Andrew Lutomirski
2011-05-21 13:34 ` Andrew Lutomirski
2011-05-21 14:14 ` KOSAKI Motohiro
2011-05-21 14:14 ` KOSAKI Motohiro
2011-05-21 14:44 ` Minchan Kim
2011-05-21 14:44 ` Minchan Kim
2011-05-22 12:22 ` Andrew Lutomirski
2011-05-22 12:22 ` Andrew Lutomirski
2011-05-22 23:12 ` Minchan Kim
2011-05-22 23:12 ` Minchan Kim
2011-05-23 16:42 ` Andrea Arcangeli
2011-05-23 16:42 ` Andrea Arcangeli
2011-05-23 17:35 ` Mel Gorman
2011-05-23 17:35 ` Mel Gorman
2011-05-24 1:19 ` Andrew Lutomirski
2011-05-24 1:34 ` Minchan Kim
2011-05-24 1:34 ` Minchan Kim
2011-05-24 11:24 ` Andrew Lutomirski
2011-05-24 11:24 ` Andrew Lutomirski
2011-05-24 11:55 ` Andrew Lutomirski
2011-05-25 0:43 ` KOSAKI Motohiro
2011-05-25 0:43 ` KOSAKI Motohiro
2011-05-21 14:31 ` Minchan Kim
2011-05-21 14:31 ` Minchan Kim
2011-05-19 14:51 ` Wu Fengguang
2011-05-19 14:51 ` Wu Fengguang
2011-05-19 15:00 ` Andrew Lutomirski
2011-05-19 15:00 ` Andrew Lutomirski
2011-05-20 0:20 ` Minchan Kim
2011-05-20 0:20 ` Minchan Kim
2011-05-15 22:40 ` Minchan Kim
2011-05-15 22:40 ` Minchan Kim
2011-05-17 5:52 ` Wu Fengguang
2011-05-17 5:52 ` Wu Fengguang
2011-05-17 6:26 ` Minchan Kim
2011-05-17 6:26 ` Minchan Kim
2011-05-20 10:40 ` Andrea Arcangeli
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=20110520153346.GA1843@barrios-desktop \
--to=minchan.kim@gmail.com \
--cc=aarcange@redhat.com \
--cc=andi@firstfloor.org \
--cc=fengguang.wu@intel.com \
--cc=hannes@cmpxchg.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@mit.edu \
--cc=mgorman@suse.de \
--cc=riel@redhat.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 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.