RE: [Xen-users] crazy SWAP and RAM idea

["Steffen Heil" <lists@xxxxxxxxxxxxxxx>]

Hi

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

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

Regrads,
  Steffen

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

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users