| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] [PATCH] linux/balloon:don't allow ballooningdowna domain
> >OK, I think I am understanding it a bit better:
> >the max_pfn part is just adding in some "slop"
> >which is a fraction of total main memory which
> >is growing smaller (roughly logarithmically)
> >as memory grows larger. I'm still not sure about
> >the magic values in MB2PAGES though... I'm guessing
> >these were gathered somehow experimentally?
>
> I have to defer to the original author here - Kurt?
Eagerly awaiting... In addition to cutting it
in half, I subtracted another 10MB (in a memory=512
domain) and still didn't see any OOMs, though my
testing was admittedly limited.
> >With the "divide result of your algorithm by two",
> >I was able to get thirteen 512MB domains (idle
> >for now) running on a 2GB system.
>
> You mean ballooned-down domains, right? Perhaps using your
> self-ballooning change? I have to admit I'm a little nervous
> about attempting to overcommit memory in this way in a
> production environment, but as long as this depends on a
> decision of the operator it's certainly a good option to have.
Yes, ballooned-down domains. In fact with minimum_target()
modified as above (half of algorithm minus 10MB) and
a variable load (repeating { compile xen; sleep(30<rand<541) }),
I got fifteen 512MB domains running on a 2GB systems.
Agreed that there are many environments where this kind
of ballooning would cause performance problems (or worse).
However, there are certainly some environments (and some
competitive situations ;-) where one might choose to
tradeoff performance to run more VMs per physical machine.
Dan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home