linux-kernel - Re: [PATCH] Make is_mem_section_removable more conformable with offlining code

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100902082829.GA10265@tiehlicka.suse.cz>
Date:	Thu, 2 Sep 2010 10:28:29 +0200
From:	Michal Hocko <mhocko@...e.cz>
To:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Cc:	Wu Fengguang <fengguang.wu@...el.com>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Kleen, Andi" <andi.kleen@...el.com>,
	Haicheng Li <haicheng.li@...ux.intel.com>,
	Christoph Lameter <cl@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Mel Gorman <mel@...ux.vnet.ibm.com>
Subject: Re: [PATCH] Make is_mem_section_removable more conformable with
 offlining code

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@...e.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@...e.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?

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

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?

> 
> Thanks,
> -Kame
> 
> 

-- 
Michal Hocko
L3 team 
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9    
Czech Republic
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/