From: Andrew Morton <akpm@linux-foundation.org>
To: Minchan Kim <minchan@kernel.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Subject: Re: [PATCH v3] memory-hotplug: fix zone stat mismatch
Date: Thu, 20 Sep 2012 14:42:32 -0700 [thread overview]
Message-ID: <20120920144232.a3e8b60f.akpm@linux-foundation.org> (raw)
In-Reply-To: <1348123405-30641-1-git-send-email-minchan@kernel.org>
On Thu, 20 Sep 2012 15:43:25 +0900
Minchan Kim <minchan@kernel.org> wrote:
> During memory-hotplug, I found NR_ISOLATED_[ANON|FILE]
> are increasing so that kernel are hang out.
>
> The cause is that when we do memory-hotadd after memory-remove,
> __zone_pcp_update clear out zone's ZONE_STAT_ITEMS in setup_pageset
> although vm_stat_diff of all CPU still have value.
>
> In addtion, when we offline all pages of the zone, we reset them
> in zone_pcp_reset without drain so that we lost zone stat item.
>
Here's what I ended up with for a changelog:
: During memory-hotplug, I found NR_ISOLATED_[ANON|FILE] are increasing,
: causing the kernel to hang. When the system doesn't have enough free
: pages, it enters reclaim but never reclaim any pages due to
: too_many_isolated()==true and loops forever.
:
: The cause is that when we do memory-hotadd after memory-remove,
: __zone_pcp_update() clears a zone's ZONE_STAT_ITEMS in setup_pageset()
: although the vm_stat_diff of all CPUs still have values.
:
: In addtion, when we offline all pages of the zone, we reset them in
: zone_pcp_reset without draining so we loss some zone stat item.
As memory hotplug seems fairly immature and broken, I'm thinking
there's no point in backporting this into -stable. And I don't *think*
we really need it in 3.6 either? (It doesn't apply cleanly to current
mainline anyway - I didn't check why).
--
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: Andrew Morton <akpm@linux-foundation.org>
To: Minchan Kim <minchan@kernel.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Subject: Re: [PATCH v3] memory-hotplug: fix zone stat mismatch
Date: Thu, 20 Sep 2012 14:42:32 -0700 [thread overview]
Message-ID: <20120920144232.a3e8b60f.akpm@linux-foundation.org> (raw)
In-Reply-To: <1348123405-30641-1-git-send-email-minchan@kernel.org>
On Thu, 20 Sep 2012 15:43:25 +0900
Minchan Kim <minchan@kernel.org> wrote:
> During memory-hotplug, I found NR_ISOLATED_[ANON|FILE]
> are increasing so that kernel are hang out.
>
> The cause is that when we do memory-hotadd after memory-remove,
> __zone_pcp_update clear out zone's ZONE_STAT_ITEMS in setup_pageset
> although vm_stat_diff of all CPU still have value.
>
> In addtion, when we offline all pages of the zone, we reset them
> in zone_pcp_reset without drain so that we lost zone stat item.
>
Here's what I ended up with for a changelog:
: During memory-hotplug, I found NR_ISOLATED_[ANON|FILE] are increasing,
: causing the kernel to hang. When the system doesn't have enough free
: pages, it enters reclaim but never reclaim any pages due to
: too_many_isolated()==true and loops forever.
:
: The cause is that when we do memory-hotadd after memory-remove,
: __zone_pcp_update() clears a zone's ZONE_STAT_ITEMS in setup_pageset()
: although the vm_stat_diff of all CPUs still have values.
:
: In addtion, when we offline all pages of the zone, we reset them in
: zone_pcp_reset without draining so we loss some zone stat item.
As memory hotplug seems fairly immature and broken, I'm thinking
there's no point in backporting this into -stable. And I don't *think*
we really need it in 3.6 either? (It doesn't apply cleanly to current
mainline anyway - I didn't check why).
next prev parent reply other threads:[~2012-09-20 21:42 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-20 6:43 [PATCH v3] memory-hotplug: fix zone stat mismatch Minchan Kim
2012-09-20 6:43 ` Minchan Kim
2012-09-20 7:21 ` Yasuaki Ishimatsu
2012-09-20 7:21 ` Yasuaki Ishimatsu
2012-09-20 7:37 ` Minchan Kim
2012-09-20 7:37 ` Minchan Kim
2012-09-20 21:42 ` Andrew Morton [this message]
2012-09-20 21:42 ` Andrew Morton
2012-09-20 23:36 ` Minchan Kim
2012-09-20 23:36 ` Minchan Kim
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=20120920144232.a3e8b60f.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=isimatu.yasuaki@jp.fujitsu.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.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.