[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <45E8594B.6020904@austin.ibm.com>
Date: Fri, 02 Mar 2007 11:05:15 -0600
From: Joel Schopp <jschopp@...tin.ibm.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
CC: Andrew Morton <akpm@...ux-foundation.org>,
Mel Gorman <mel@...net.ie>, npiggin@...e.de,
clameter@...r.sgi.com, mingo@...e.hu, arjan@...radead.org,
mbligh@...igh.org, linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: The performance and behaviour of the anti-fragmentation related
patches
Linus Torvalds wrote:
>
> On Thu, 1 Mar 2007, Andrew Morton wrote:
>> So some urgent questions are: how are we going to do mem hotunplug and
>> per-container RSS?
The people who were trying to do memory hot-unplug basically all stopped waiting for
these patches, or something similar, to solve the fragmentation problem. Our last
working set of patches built on top of an earlier version of Mel's list based solution.
>
> Also: how are we going to do this in virtualized environments? Usually the
> people who care abotu memory hotunplug are exactly the same people who
> also care (or claim to care, or _will_ care) about virtualization.
Yes, we are. And we are very much in favor of these patches. At last year's OLS
developers from IBM, HP, Xen coauthored a paper titled "Resizing Memory with Balloons
and Hotplug". http://www.linuxsymposium.org/2006/linuxsymposium_procv2.pdf Our
conclusion was that ballooning is simply not good enough and we need memory
hot-unplug. Here is a quote from the article I find relevant to today's discussion:
"Memory Hotplug remove is not in mainline.
Patches exist, released under the GPL, but are
only occasionally rebased. To be worthwhile
the existing patches would need either a remappable
kernel, which remains highly doubtful, or
a fragmentation avoidance strategy to keep migrateable
and non-migrateable pages clumped
together nicely."
At IBM all of our Power4, Power5, and future hardware supports a lot of
virtualization features. This hardware took "Best Virtualization Solution" at
LinuxWorld Expo, so we aren't talking research projects here.
http://www-03.ibm.com/press/us/en/pressrelease/20138.wss
> My personal opinion is that while I'm not a huge fan of virtualization,
> these kinds of things really _can_ be handled more cleanly at that layer,
> and not in the kernel at all. Afaik, it's what IBM already does, and has
> been doing for a while. There's no shame in looking at what already works,
> especially if it's simpler.
I believe you are talking about the zSeries (aka mainframe) because the rest of IBM
needs these patches. zSeries built their whole processor instruction set, memory
model, etc around their form of virtualization, and I doubt the rest of us are going
to change our processor instruction set that drastically. I've had a lot of talks
with Martin Schwidefsky (the maintainer of Linux on zSeries) about how we could do
more of what they do and the basic answer is we can't because what they do is so
fundamentally incompatible.
While I appreciate that we should all dump our current hardware and buy mainframes it
seems to me that an easier solution is to take a few patches from Mel and work with
the hardware we already have.
-
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