linux-kernel - Re: [Xen-devel] Re: GSoC 2010 - Migration from memory ballooning to memory hotplug in Xen

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: <20100709003409.GC15950@basil.fritz.box>
Date:	Fri, 9 Jul 2010 02:34:09 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Andi Kleen <andi@...stfloor.org>,
	Daniel Kiper <dkiper@...-space.pl>,
	xen-devel@...ts.xensource.com, linux-kernel@...r.kernel.org
Subject: Re: [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@...ux.intel.com -- Speaking for myself only.
--
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/