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]
Date:	Fri, 09 Jul 2010 00:32:05 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Daniel Kiper <dkiper@...-space.pl>
Cc:	xen-devel@...ts.xensource.com, linux-kernel@...r.kernel.org,
	jeremy@...p.org
Subject: Re: GSoC 2010 - Migration from memory ballooning to memory hotplug in Xen

Daniel Kiper <dkiper@...-space.pl> writes:
>
> OK, let's go to details. When I was playing with Xen I saw that
> ballooning does not give possibility to extend memory over boundary
> declared at the start of system. Yes, I know that is by desing however
> I thought that it is a limitation which could by very annoing in some
> enviroments (I think especially about servers). That is why I decided to
> develop some code which remove that one. At the beggining I thought
> that it should be replaced by memory hotplyg however after some test
> and discussion with Jeremy we decided to link balooning (for memory
> removal) with memory hotplug (for extending memory above boundary
> declared at the startup of system). Additionaly, we decided to implement
> this solution for Linux Xen gustes in all forms (PV/i386,x86_64 and
> HVM/i386,x86_64).

While you can do that the value is not very large because you
could just start the guests with more memory, but ballooned in 
the first place (so that they don't actually use it) 

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).

One trap is also that memory hotadd is a frequent source of regressions,
so you'll likely run into existing bugs.

-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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ