Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19

Ingo Molnar
2005-11-02T09:17:39Z

* Nick Piggin <nickpiggin@yahoo.com.au> wrote:

> Ingo Molnar wrote:
>
> >really, once you accept that, the path out of this mess becomes 'easy':
> >we _have to_ compromise on the feature side! And the moment we give up
> >the notion of 'generic kernel RAM' and focus on the hot-removability of
> >a limited-functionality zone, the complexity of the solution becomes
> >three orders of magnitude smaller. No fragmentation avoidance necessary.
> >No 'have to handle dozens of very hard problems to become 99%
> >functional' issues. Once you make that zone an opt-in thing, it becomes
> >much better from a development dynamics point of view as well.
> >
>
> I agree. Especially considering that all this memory hotplug usage for
> hypervisors etc. is a relatively new thing with few of our userbase
> actually using it. I think a simple zones solution is the right way to
> go for now.

btw., virtualization is pretty much a red herring here. Xen already has
a 'balooning driver', where a guest OS can give back unused RAM on a
page-granular basis. This is an advantage of having a fully virtualized
guest OS. That covers 99% of the 'remove RAM' needs. So i believe the
real target audience of hot-unplug is mostly limited to hardware-level
RAM unplug.

[ Xen also offers other features like migration of live images to
another piece of hardware, which further dampen the cost of
virtualization (mapping overhead, etc.). With hot-remove you dont get
such compound benefits of a conceptually more robust and thus more
pervasive approach. ]

Ingo