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-users] crazy SWAP and RAM idea

To: <tim.post@xxxxxxxxxxxxxxx>, "'Tom Brown'" <tbrown@xxxxxxxxxxxxx>
Subject: RE: [Xen-users] crazy SWAP and RAM idea
From: "Steffen Heil" <lists@xxxxxxxxxxxxxxx>
Date: Sun, 10 Sep 2006 20:33:20 +0200
Cc: xen-users@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sun, 10 Sep 2006 11:34:18 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1157869439.10056.282.camel@cable-202-128-54-171>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcbUofatViB2ca03Q92swiZhC7c84wAZDL1w

> One of the biggest advantages to using Xen is that 
> malloc()'ing processes that need to spawn children are able 
> to do so in cache. This gives the dom-u performance that a 
> non virtualized server would enjoy.

Could you explain this in more detail, please?

> SQL, Web , Email, All services will need to 
> fork upon every connection.

No. Good current software doesn't. My SQL and Web-Servers are threaded so
there is no need to fork, still searching for a way for email...

> You also risk DB corruption, (not to mention inode corruption 
> [are you using ext3? I hope not, or you're looking to start 
> grepping for your data using strings you hope exist in the 
> files you lost] ). Just wait until a dom-u is being hammered 
> and dom-0 experiences an unorderly shutdown, hope you've 
> polished up on your regex to find your data :)

I don't understand that at all. First, if ext3 (which DOES have journaling)
looses any data on unclean shutdown, then it is faulty. And yes, I use it on
several machines. And secondly I think that farly depends how you implement
domU partitions. Mine are LVM...

> Why shoot your OS in the foot intentionally when other means 
> exist to accomplish what you want to do? I just don't get 
> it.. All your doing is not only retarding Xen, but also your 
> guest OS's and their services ..
> for what purpose?

Hey come on. I wrote "crazy idea" myself and I did definitely not plan to
take this to production or customer domains...
It was an idea and I thought maybe it's worth some discussion (as I still

Remember that the main idea here has NOT been to do something as "ram
bursts" (if I understand that correcty as automatic changes of domU memory),
but to give dom0 a better way to control disk caching instead of relying on
every single domain to have it's own cache.

The idea arose from a situation where I had the same (READ-ONLY) partition
mounted on several domains which ALL had a lot of that data in cache
memory... (Still working on problems with that machine, as I did't find a
way to stop that.)


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Xen-users mailing list