WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Xen memory allocation

To: David Becker <becker@xxxxxxxxxxx>
Subject: Re: [Xen-devel] Xen memory allocation
From: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>
Date: Fri, 04 Jun 2004 14:26:46 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx, Ian.Pratt@xxxxxxxxxxxx
Delivery-date: Fri, 04 Jun 2004 14:28:18 +0100
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: Your message of "Fri, 04 Jun 2004 09:07:36 EDT." <20040604130736.GE11293@xxxxxxxxxxx>
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>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
 
> " We are considering implementing a shared buffer cache, but haven't
> 
> A memory management scheme that would be useful here is a lowater/hiwater
> setting for memory allocatation to each domain.
> This would allow phys memory to be oversubscribed by the domains.
> Then xen could slosh memory between domains based on demand.
> 
> It seems like the balloon driver system would have had the groundwork for 
> this.
> I know that bit of things has rotted, but when it worked it ought to have
> demonstrated the mechansisms needed for a  lowater/hiwater policy.

The balloon driver enables a domain to give back physical memory
pages or request new memory. Unlike e.g. vmware this isn't
transparent to the guest OS, but there are actually good reasons
why you don't want it to be transparent (the guest OS is in a
much better position to make sensible paging decisions than the
VMM).

Fixing the balloon driver should be very straight forward. We
then need to add a control interface so that domain0 can tell
other domains what their current memory allocation target is
(when reducing a domain's target dom0 should give them a few
hundred milliseconds to hand back the pages, then kill the domain
if it doesn't comply).

It would be really nice to get this in the 2.0 release. Any
volunteers to help out? ;-)


Thanks,
Ian


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel

<Prev in Thread] Current Thread [Next in Thread>