All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jacob Gorm Hansen <jacobg@diku.dk>
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: Peri Hankey <mpah@thegreen.co.uk>,
	urmk@reason.marist.edu, Rik van Riel <riel@redhat.com>,
	xen-devel@lists.sourceforge.net
Subject: Re: copy on write memory
Date: Fri, 19 Nov 2004 13:02:01 +0100	[thread overview]
Message-ID: <419DE0B9.4030502@diku.dk> (raw)
In-Reply-To: <E1CV6Tt-0000ea-00@mta1.cl.cam.ac.uk>

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).

Jacob


-------------------------------------------------------
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

  reply	other threads:[~2004-11-19 12:02 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-15 22:01 copy on write memory Peri Hankey
2004-11-16  0:35 ` Rik van Riel
2004-11-16  9:44   ` Peri Hankey
2004-11-16  9:51     ` Peri Hankey
2004-11-16 15:27     ` urmk
2004-11-16 16:17       ` Mark A. Williamson
2004-11-18 16:56       ` Peri Hankey
2004-11-18 17:11         ` urmk
2004-11-18 17:25           ` Keir Fraser
2004-11-18 18:41             ` Kip Macy
2004-11-18 18:55               ` Keir Fraser
2004-11-18 19:16                 ` Kip Macy
2004-11-18 18:15           ` Peri Hankey
2004-11-19 10:35             ` Jacob Gorm Hansen
2004-11-19 10:59               ` Keir Fraser
2004-11-19 12:02                 ` Jacob Gorm Hansen [this message]
2004-11-19 14:50                   ` Keir Fraser
2004-11-22 12:42                     ` Jacob Gorm Hansen
2004-11-25 15:01                       ` of cows and clones: creating domains as clones of saved state Peri Hankey
2004-11-25 21:19                         ` Keir Fraser
2004-11-25 22:13                           ` Peri Hankey
2004-11-25 22:36                             ` Keir Fraser
2004-11-25 22:37                             ` Ian Pratt
2004-11-16 18:10     ` copy on write memory Adam Heath
2004-11-16 18:09   ` Adam Heath
2004-11-16 18:39     ` Matt Ayres

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=419DE0B9.4030502@diku.dk \
    --to=jacobg@diku.dk \
    --cc=Keir.Fraser@cl.cam.ac.uk \
    --cc=mpah@thegreen.co.uk \
    --cc=riel@redhat.com \
    --cc=urmk@reason.marist.edu \
    --cc=xen-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.