linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.cz>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Wu Fengguang <fengguang.wu@intel.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Kleen, Andi" <andi.kleen@intel.com>,
	Haicheng Li <haicheng.li@linux.intel.com>,
	Christoph Lameter <cl@linux-foundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Mel Gorman <mel@linux.vnet.ibm.com>
Subject: Re: [PATCH] Make is_mem_section_removable more conformable with offlining code
Date: Thu, 2 Sep 2010 11:24:54 +0200	[thread overview]
Message-ID: <20100902092454.GA17971@tiehlicka.suse.cz> (raw)
In-Reply-To: <20100902180343.f4232c6e.kamezawa.hiroyu@jp.fujitsu.com>

On Thu 02-09-10 18:03:43, KAMEZAWA Hiroyuki wrote:
> On Thu, 2 Sep 2010 10:28:29 +0200
> Michal Hocko <mhocko@suse.cz> wrote:
> 
> > On Thu 02-09-10 14:45:00, KAMEZAWA Hiroyuki wrote:
> > > On Wed, 1 Sep 2010 14:41:38 +0200
> > [...]
> > > > From de85f1aa42115678d3340f0448cd798577036496 Mon Sep 17 00:00:00 2001
> > > > From: Michal Hocko <mhocko@suse.cz>
> > > > Date: Fri, 20 Aug 2010 15:39:16 +0200
> > > > Subject: [PATCH] Make is_mem_section_removable more conformable with offlining code
> > > > 
> > > > Currently is_mem_section_removable checks whether each pageblock from
> > > > the given pfn range is of MIGRATE_MOVABLE type or if it is free. If both
> > > > are false then the range is considered non removable.
> > > > 
> > > > On the other hand, offlining code (more specifically
> > > > set_migratetype_isolate) doesn't care whether a page is free and instead
> > > > it just checks the migrate type of the page and whether the page's zone
> > > > is movable.
> > > > 
> > > > This can lead into a situation when we can mark a node as not removable
> > > > just because a pageblock is MIGRATE_RESERVE and it is not free.
> > > > 
> > > > Let's make a common helper is_page_removable which unifies both tests
> > > > at one place. Also let's check for MIGRATE_UNMOVABLE rather than all
> > > > possible MIGRATEable types.
> > > > 
> > > > Signed-off-by: Michal Hocko <mhocko@suse.cz>
> > > 
> > > Hmm..Why MIGRATE_RECLAIMABLE is included ?
> > 
> > AFAIU the code, MIGRATE_RECLAIMABLE are movable as well (at least that
> > is how I interpret #define GFP_MOVABLE_MASK (__GFP_RECLAIMABLE|__GFP_MOVABLE)).
> > Why should we prevent from memory offlining if we have some reclaimable
> > pages? Or am I totally misinterpreting the meaning of this flag?
> > 
> 
> RECLAIMABLE cannot be 100% reclaimable. 

OK, I see. The name is little bit misleading then. Should we comment
that?

> Then, for memory hotlug,
> I intentionally skips it and check free_area[] and LRU.
> 
> 
> > > 
> > > If MIGRATE_RCLAIMABLE is included, set_migrate_type() should check the
> > > range of pages. Because it makes the pageblock as MIGRAGE_MOVABLE after
> > > failure of memory hotplug.
> > > 
> > > Original code checks.
> > > 
> > >  - the range is MIGRAGE_MOVABLE or
> > >  - the range includes only free pages and LRU pages.
> > > 
> > > Then, moving them back to MIGRAGE_MOVABLE after failure was correct.
> > > Doesn't this makes changes MIGRATE_RECALIMABLE to be MIGRATE_MOVABLE and
> > > leads us to more fragmentated situation ?
> > 
> > Just to be sure that I understand you concern. We are talking about hot
> > remove failure which can lead to higher fragmentation, right? 
> > 
> right. 
> 
> > By the higher fragmentation you mean that all movable pageblocks (even
> > reclaimable) gets to MIGRATE_MOVABLE until we get first failure. In the
> > worst case, if we fail near the end of the zone then there is imbalance
> > in MIGRATE_MOVABLE vs. MIGRATE_RECALIMABLE. Is that what you are
> > thinking of? Doesn't this just gets the zone to the state after
> > onlining? Or is the problem if we fail somewhere in the middle?
> > 
> 
> No. My concern is pageblock type changes before/after memory hotplug failure.
> 	before isolation: MIGRATE_RECLAIMABLE
> 	after isolation failure : MIGRATE_MOVABLE

Ahh, OK I can see your point now. unset_migratetype_isolate called on
the failure path sets migrate type unconditionally as it cannot know
what was the original migration type.

What about MIGRATE_RESERVE? Is there anything that can make those
allocations fail offlining?

Thanks!

> 
> Then, the section which was RECALAIMABLE (but caused memory hotplug failure)
> turns to be MIGRATE_MOVABLE and will continue to cause memory hotplug failure.
> (Because it contains unreclaimable(still-in-use) slab.)
> 
> That means memory-hotplug success-rate goes down because of not-important check,
> and (your) customer believe "memory hotplug never works well hahaha."
> 
> The old code checks RECLAIMABLE pageblock only contains free pages or LRU pages,
> In that meaning, MIGRATE_MOVABLE check itself should be removed. It's my fault.
> 
> 
> Thanks,
> -Kame
> 

-- 
Michal Hocko
L3 team 
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9    
Czech Republic

--
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>

  reply	other threads:[~2010-09-02  9:24 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-20 14:14 [PATCH] Make is_mem_section_removable more conformable with offlining code Michal Hocko
2010-08-22  0:42 ` Wu Fengguang
2010-08-23  9:22   ` Michal Hocko
2010-08-31 12:30     ` Michal Hocko
2010-08-31 14:19     ` Wu Fengguang
2010-08-31 14:36       ` Wu Fengguang
2010-08-31 14:59         ` Wu Fengguang
2010-09-01  1:19         ` KAMEZAWA Hiroyuki
2010-09-01 12:19       ` Michal Hocko
2010-09-01 12:41         ` Michal Hocko
2010-09-02  5:45           ` KAMEZAWA Hiroyuki
2010-09-02  8:28             ` Michal Hocko
2010-09-02  9:03               ` KAMEZAWA Hiroyuki
2010-09-02  9:24                 ` Michal Hocko [this message]
2010-09-02 11:19                   ` Hiroyuki Kamezawa
2010-09-02 13:18                     ` Michal Hocko
2010-09-02 14:19                       ` Hiroyuki Kamezawa
2010-09-02 14:39                         ` Michal Hocko
2010-09-02 15:05                           ` Michal Hocko
2010-09-03  3:10                             ` [PATCH 0/2 v2] " KAMEZAWA Hiroyuki
2010-09-03  3:11                               ` [PATCH 1/2][BUGFIX] fix next active pageblock calculation KAMEZAWA Hiroyuki
2010-09-03  3:14                               ` [PATCH 2/2] Make is_mem_section_removable more conformable with offlining code KAMEZAWA Hiroyuki
2010-09-03  8:25                                 ` Michal Hocko
2010-09-03  9:13                                   ` KAMEZAWA Hiroyuki
2010-09-03  9:50                                     ` Michal Hocko
2010-09-03 10:05                                       ` KAMEZAWA Hiroyuki
2010-09-03 11:01                                         ` Michal Hocko
2010-09-03 11:42                                         ` [PATCH 2/2] Make is_mem_section_removable more conformable with offlining code v3 Michal Hocko
2010-09-04  2:55                                           ` Wu Fengguang
2010-09-06  9:16                                             ` Michal Hocko
2010-09-03  9:15                                   ` [PATCH 2/2] Make is_mem_section_removable more conformable with offlining code Michal Hocko
2010-09-03  9:24                                     ` KAMEZAWA Hiroyuki
2010-09-03  7:54                               ` [PATCH 0/2 v2] " Michal Hocko
2010-09-03  7:57                               ` [PATCH 3/2][BUGFIX] fix memory isolation notifier return value check KAMEZAWA Hiroyuki
2010-09-03 20:48                                 ` Andrew Morton
2010-09-03 22:05                                   ` Hiroyuki Kamezawa

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=20100902092454.GA17971@tiehlicka.suse.cz \
    --to=mhocko@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=andi.kleen@intel.com \
    --cc=cl@linux-foundation.org \
    --cc=fengguang.wu@intel.com \
    --cc=haicheng.li@linux.intel.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mel@linux.vnet.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).