[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1225812111.12673.577.camel@nimitz>
Date: Tue, 04 Nov 2008 07:21:51 -0800
From: Dave Hansen <dave@...ux.vnet.ibm.com>
To: "Rafael J. Wysocki" <rjw@...k.pl>
Cc: Nigel Cunningham <ncunningham@...a.org.au>,
Matt Tolentino <matthew.e.tolentino@...el.com>,
linux-pm@...ts.osdl.org, Dave Hansen <haveblue@...ibm.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org, pavel@...e.cz,
Mel Gorman <mel@...net.ie>, Andy Whitcroft <apw@...dowen.org>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [linux-pm] [PATCH] hibernation should work ok with memory
hotplug
On Tue, 2008-11-04 at 09:54 +0100, Rafael J. Wysocki wrote:
> To handle this, I need to know two things:
> 1) what changes of the zones are possible due to memory hotplugging
> (i.e. can they grow, shring, change boundaries etc.)
All of the above.
> 2) what kind of locking is needed to prevent zones from changing.
The amount of locking is pretty minimal. We depend on some locking in
sysfs to keep two attempts to online from stepping on the other.
There is the zone_span_seq*() set of functions. These are used pretty
sparsely, but we do use them in page_outside_zone_boundaries() to notice
when a zone is resized.
There are also the pgdat_resize*() locks. Those are more for internal
use guarding the sparsemem structures and so forth.
Could you describe a little more why you need to lock down zone
resizing? Do you *really* mean zones, or do you mean "the set of memory
on the system"? Why walk zones instead of pgdats?
-- Dave
--
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/
Powered by blists - more mailing lists