lkml.org 
[lkml]   [2010]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Xen-devel] Re: GSoC 2010 - Migration from memory ballooning to memory hotplug in Xen
> Yes.  Another approach would be to fiddle with the E820 maps early at
> boot to add more RAM, but then early_reserve it and hand it over to the
> control of the balloon driver. But it does mean you need to statically
> come up with the max ever at boot time.

You need to do that too for memory hotadd -- you need predeclared
hotadd regions. Linux mainly needs it to know in which node
to put the memory. Other OS use it for other things too.

> > The only advantage of using memory hotadd is that the mem_map doesn't
> > need to be pre-allocated, but that's only a few percent of the memory.
> >
> > So it would only help if you want to add gigantic amounts of memory
> > to a VM (like >20-30x of what it already has).
> >
>
> That's not wildly unreasonable on the face of it; consider a domain
> which starts at 1GB but could go up to 32GB as demand requires. But

The programs which need 32GB will probably not even start in 1GB :)

> > One trap is also that memory hotadd is a frequent source of regressions,
> > so you'll likely run into existing bugs.
>
> That could be painful, but I expect the main reason for regressions is
> that the code is fairly underused. Adding new users should help.

Yes, and we fixed a lot of the bugs, but still a lot of them
were tricky and frankly new ones might be too difficult for a SoC.

-Andi

--
ak@linux.intel.com -- Speaking for myself only.


\
 
 \ /
  Last update: 2010-07-09 02:37    [W:0.099 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site