This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] About resource reclamation

To: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] About resource reclamation
From: Xuxian Jiang <jiangx@xxxxxxxxxxxxx>
Date: Sat, 11 Oct 2003 16:35:35 -0500 (EST)
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx, Xuxian Jiang <jiangx@xxxxxxxxxxxxx>
Delivery-date: Sat, 11 Oct 2003 22:36:26 +0100
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: <E1A80hX-0004jc-00@xxxxxxxxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
References: <E1A80hX-0004jc-00@xxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
On Fri, 10 Oct 2003, Ian Pratt wrote:

> > I believe Xen has the similar primitives for requesting resources from
> > GuestOS side. And it seems reasonable and practical to add the reverse
> > functionality rescinding resource usage back from GuestOS. Such approach
> > may not be possible considering UML or VMWare, but with Xen, it should be
> > possible since modification on GuestOS can be made.
> Absolutely -- that's one of the big wins of para-virtualization.
> For example, I'm looking forward to being able to send a message
> from domain 0 to another domain saying "I wish you to release 4MB
> of memory as I have another domain that is prepared to pay more
> for it. You have 100ms to comply, or be terminated with extreme
> prejudice." ;-)
> > In one situation, where several domains have been created using overbooked
> > resources, would it be nice to have some resouce reclamation capability
> > which requires the cooperation between Xen and supported GuestOS?
> The general plan is to avoid overbooking "guaranteed" resources
> to domains, but allow domains some additional resources on a best
> effort proportional share basis.
> For example, we've got plans to add support for a shared buffer
> cache using 'unused' memory, along with a 'swap cache' to speed
> up swapping.

Nice thought.

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.

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.

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.

Xuxian Jiang        (765)494-2957
Department of Computer Sciences
Purdue University

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