All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Tom Cranbrook" <tcranbrook@australia.edu>
To: "Mark A. Williamson" <mark.williamson@cl.cam.ac.uk>,
	tcranbrook@australia.edu, xen-devel@lists.sourceforge.net
Subject: Re: Xen - Mosix cluster
Date: Sat, 16 Oct 2004 15:21:09 -0400	[thread overview]
Message-ID: <41724f5e.129b.0@australia.edu> (raw)

>
>Since Xen lives at the bottom of the stack, this isn't really possible -
Xen 
>itself is really intimately tied to the specific machine its working on. 
In 
>contrast, Mosix can provide users with the illusion of a big machine but
it's 
>intimitely tied into the Linux kernel.
>
>I don't know so much about OpenSSI, how does that abstract things to the
user?
>
SSI presents a single instance OS environment, one file structure, one name
space, one set of services, one proccess list in /proc , that reflects the
conbined resources of the nodes.  Each node machine is totally assemilated
into the one image. I'm not sure of this, but I believe a node can not even
function as a terminal to the SSI.  It's a headless boot off the network.

In Mosix, each node is running an indenpendent OS environment and its own
set of services.  A remote node only comes into play if any one node maxes
out and migrates one of its processes elsewhere to lighten the load.  Each
node can be a fully functional workstation.



>> This would also allow a high demand 
>> OS environment to grow past the single machine limit.  This might also
help
>> with issues of bringing nodes on and off line.
>
>This leads to an interesting thought though - Xen does accurate resource 
>accounting on what domains have used.  That's one of its strengths.  A
cool 
>idea (although not one that'd necessarily get done) that'd partially
address 
>your problem would be to plug Xend into Mosix's process migration
mechanisms.
>
>e.g. only allow a process migration to another node if the domain owner
has 
>paid enough and then keep track of the resource usage on the remote node
*as 
>well*, so that the total resource usage is known.  One could imagine
creating 
>XenLinux/Mosix domains on other nodes on-demand when the user's virtual 
>machine wants to migrate a compute-intensive process.  (Domains running in
a 
>ramdisk only take a few hundred milliseconds to start, so this is quite 
>feasible).
>
>This way one could get some of the advantages you mention and retain the 
>strong isolation, resource accounting, etc.
>
>I'll have a think about that, since it does sound kinda cool ;-)
>
>Mark
>





-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

             reply	other threads:[~2004-10-16 19:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-16 19:21 Tom Cranbrook [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-10-16 15:17 Xen - Mosix cluster Tom Cranbrook
2004-10-16 17:26 ` Mark A. Williamson
2004-10-15 13:34 Tom Cranbrook
2004-10-15 14:11 ` Mark A. Williamson

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=41724f5e.129b.0@australia.edu \
    --to=tcranbrook@australia.edu \
    --cc=mark.williamson@cl.cam.ac.uk \
    --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.