Re: [PATCH] Make is_mem_section_removable more conformable withofflining code

[KAMEZAWA Hiroyuki]

On Thu, 2 Sep 2010 10:28:29 +0200
Michal Hocko <mhocko@xxxxxxx> 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@xxxxxxx>
> > > 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@xxxxxxx>
> > 
> > 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. 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

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/