| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] About resource reclamation
> Another idea related to this is to provide one memory pool, which can be
> shared across multiple domains according to some policies, like
> proportional sharing. Quick check of Xen shows that Xen is providing
> *very* strong memory protection via prior reservation. Such clear-cut
> *slicing * of memory may not achieve overall optimal performance.
Our intention is to expose real resources to domains and have
them optimise their behaviour accordingly. If you are `charging'
domains for the memory they use, it's in their interests to use
the balloon driver to try to reduce their memory footprint and
give pages back the system, or buy more pages if they can
usefully exploit it. Our intention would be to run the system at
something like 75% memory utilization, making the remaining
memory available for use as shared buffer cache and swap cache
(on a proportional share basis).
> Another questions related to the scalability of Xen approach. I believe
> the most limiting factor for scalability would be the amount of memory
> available. Considering fixed memory size, could it be potentially possible
> to emulate the GuestOS memory with disk files with mmap-similar mechanism.
> It is not necessary that whole GuestOS memory be emulated, but even
> partial emulation could provide *nice* and *desirable* tradeoff between
> performance and scalability.
Our goal was to have Xen comfortably support 100 domains. Results
in the SOSP paper show that using the balloon driver to swap out
all pageable memory its possible to get the memory footprint of
quiescent domains down to just 2-3MB. Hence, running 1000 domains
is already a possibility.
> I have experiemented Xen to create 10 domains each with 60M on top of one
> host node with 750M and afterwards failed to create new one without
> destroying exiting ones. In some cases, we may want to degrade the
> performance of new created domains but not obvious *rejection* to create
> new domains.
Within Xen, its our view that we want strong admission control
rather than going down the rat hole of implementing paging within
the VMM. It's down to domain0 to request other domains to free up
some memory if it wants to create a new domain.
Ian
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
|
|
| |
|
Home