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] copy on write memory

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] copy on write memory
From: Jacob Gorm Hansen <jacobg@xxxxxxx>
Date: Fri, 19 Nov 2004 13:02:01 +0100
Cc: Peri Hankey <mpah@xxxxxxxxxxxxxx>, urmk@xxxxxxxxxxxxxxxxx, Rik van Riel <riel@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 19 Nov 2004 12:03:19 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
In-reply-to: <E1CV6Tt-0000ea-00@xxxxxxxxxxxxxxxxx>
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: <E1CV6Tt-0000ea-00@xxxxxxxxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 0.8 (X11/20040926)
Keir Fraser wrote:
This would end up pushing policy into Xen -- what happens when memory
is fully committed, some domain has given up a bunch of his
exclusively-owned pages by buying into the shared table, and now he
has a slew of CoW faults and wants to get some of his exclusive pages
back from Xen, thankyou very much?

At this point Xen needs some reclamation policy (saying that Xen will
guarantee to have enough pages around to satisfy these requests is not
possible, since the point of the sharing is to be able to
"over-reserve" memory). It needs to decide which pages to reclaim,
then have a mechanism for reclaiming them which will probably involve
communicating up to the domains concerned in advance and setting
timeouts by when they must relinquish their mappings.

This is the kind of thing I would prefer to implement outside Xen.

Could the same thing not work using an event-channel rather than a hypercall then? I guess you basically do the same when giving your pages away for a driver to fill them up with data? My main point is that the domains have better knowledge about what pages are likely to be shareable than dom0 or Xen has, and so should volunteer to share them, and somehow be rewarded.

The problem of reclamation-policy will exist for any solution that over-reserves memory, including the transparent VMWare system. For some pages, like the guest OS kernel text area, it would be ok to remove these pages from the domain's allowance for good -- it will not need to CoW these, and the domain builder could simply build that part of the domain from shared pages.

Perhaps this should just be a one-way street, you give up pages to be nice to others (and get cheaper hosting or whatever kind of reward you can think of in return), and then you lose the right to write to them for good. Should you need more writable pages, you will have to re-grow your reservation, and if that fails you will need to flush some slabs or buffer caches or or page stuff to disk or whatever you do in Linux when you have memory pressure. Ultimately you may want to migrate to a less loaded machine.

It seems to me any other kind of solution will allow a malicious domain to affect the performance of innocent domains by repeatedly sharing and unsharing its pages (whether by explicit hypercall or by placing popular vs random data in them).


This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
Xen-devel mailing list