From: "Tom Cranbrook" <tcranbrook@australia.edu>
To: "Mark A. Williamson" <mark.williamson@cl.cam.ac.uk>,
xen-devel@lists.sourceforge.net, tcranbrook@australia.edu
Subject: Re: Xen - Mosix cluster
Date: Sat, 16 Oct 2004 11:17:43 -0400 [thread overview]
Message-ID: <41721650.6134.0@australia.edu> (raw)
>> idea. As a side effect, the resource usage of any on OS environment is
>> also limited at a maximum by the limites on any single node machine.
(It's
>> also limited by configuration, I know.)
>
>All true. If a node is overloaded, you might migrate some domains off it.
>
True, but the limit still remains.
Perhaps I am trying to have my cake and eat it too. The advantages of Xen
are strong isolation of OS environments and more efficent use of resources
on large capacity machines. The advantage of Mosix and OpenSSI is to
combine multiple machines to run an OS environment greater than a single
machine, using two different approaches. In a sense, these systems and Xen
are at opposite purposes. It would seem to me that putting OpenSSI 'on
top' of Zen would cancel out the benifits of Xen, and would not enhance the
benifits of SSI. (other than creating a test system for SSI. That makes a
lot of sense.) Mosix 'on top' of Xen is probably not useful either since
the advantage of Mosix is to move a demanding process to another machine,
not to another OS environemnt on the same machine.
If, however, Xen were on top of the stack, we may be able to achive both
purposes. The cluster hardware can be consolidated to support a single
base OS environment that can be distributed at the process level of
granularity. Then Xen builds on this resource pool to provide the guest OS
environment isolation. From Xens point of view, it would just have a way
big honker of a machine to work with. 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 would still leave us with a single machine speed limit for any one
proccess, plus overhead, but ... hey ... one thing at a time.
-------------------------------------------------------
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
next reply other threads:[~2004-10-16 15:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-16 15:17 Tom Cranbrook [this message]
2004-10-16 17:26 ` Xen - Mosix cluster Mark A. Williamson
-- strict thread matches above, loose matches on Subject: below --
2004-10-16 19:21 Tom Cranbrook
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=41721650.6134.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.