[Gllug] Xen - bit of a ramble
Andy Smith
andy at lug.org.uk
Tue May 16 16:59:52 UTC 2006
On Tue, May 16, 2006 at 02:51:36PM +0100, Matthew Cooke wrote:
> I don't know how "fair scheduling" works on solaris, but yes you get a
> share of the CPU or to be more accurate you get a guaranteed minimum CPU
> time.
>
> So on one machine my Xen Vm is roughly 1/8th of the machine. This
> guarantees me 1/8th of the CPU time (minus a small overhead). Most of the
> time I actually get nearer 100% of the CPU time since the other vms aren't
> heavily loaded but I am "roughly" guarantees to get at least my 1/8th. It's
> the ability to effectively use other VMs unused CPU cycles that makes a
> hosted Xen solution quite cost efficient.
There are also alternate scheduling algorithms that allow you to
give a weighting to certain domains, e.g. you can say "domain foo is
allowed twice as much CPU time as any of the others". I've not
investigated these, they look somewhat scary to configure, but I
hear they do work.
> Memory allocation is partitioned differently, you get a physical fixed
> amount of ram. This is real ram unlike some other virtualisation solutions
> which allow you to share ram a make it appear all VM's have more memory
> than is actually available.
Bursting of RAM would be really handy.. Say my server has 4GiB RAM and 4
domUs each with 500MiB, that's only ~2GiB so it would be desirable
to allow a domU that needed it to use more than 500MiB -- the RAM is
sitting wasted otherwise. If I loaded another domU and there wasn't
enough RAM left for its committed amount then some should be taken
from another domU that is overcommitted, and replaced with swap.
You can give and take RAM to/from a domU with xm commands, but I don't
see how to hack together this sort of thing that way as I don't know
how to tell when a domain is under memory pressure: Linux does
sometimes use swap even when it does not need to, as it swaps out
unused data and gives the RAM to disk cache.
Also I don't know if there is any work ongoing on IO scheduling as I
think by default that isn't necessarily fair (i.e. with 8 domUs it
is possible for one domU to use more than 7/8ths the available IO
bandwidth).
Cheers,
Andy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: Digital signature
URL: <http://mailman.lug.org.uk/pipermail/gllug/attachments/20060516/462edf04/attachment.pgp>
-------------- next part --------------
--
Gllug mailing list - Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug
More information about the GLLUG
mailing list