From: Karim Yaghmour <karim@opersys.com>
To: linux-kernel <linux-kernel@vger.kernel.org>
Subject: SMP clusters, CC-Clusters and friends ...
Date: Fri, 05 Sep 2003 00:10:55 -0400 [thread overview]
Message-ID: <3F580CCF.5010109@opersys.com> (raw)
Having spent quite some time in the summer of 2002 figuring out many of the
various practical issues of implementing Linux SMP clusters, I was quite happy
to see some actual discussion on the topic on LKML. Unfortunately the discussion
has centered mostly on philosophical issues, and I wasn't interested very much
in those: though I believe the kernel can be made to scale, and has done so
successfully in the past, I think that an SMP cluster will always scale to a
greater number of processors than the kernel can, regardless of its state of
development (i.e. if the kernel scales well to 256 CPUs, then an SMP cluster
using said kernel will scale to N*256, N being the number of cells/nodes to
which the upper-layer SSI software can scale). That's just for the scalability
argument, but there are other reasons why you'd want to have multiple
independent images running side-by-side, as others have pointed out ...
Personally, I'm much more interested in the how-do-we-do-this aspect of
discussion. Though Steven Cole pointed out the paper I wrote in July 2002
(thanks Steven), there's been little technical discussion around it.
Needless to say that I'd welcome any feedback anyone may have on the ideas
I put forth in the paper.
To recap, the architecture I'm suggesting has the following advantages:
- No changes to kernel's virtual memory code
- No changes to kernel's scheduler
- No changes to kernel's lock granularity
- Minimal low-level changes to kernel code
- Reuse of many existing software components
- Short-term accessibility
Unfortunately, I've been unable to put any time on this because of my
involvement in other projects and the fact that I have to pay the rent ;)
If anyone wants to take this forward on his own or if someone wants to fund
work on this, I'd be glad be to help.
Fortunately, I think the amount of work required to get a functional SMP
cluster seems to decrease with time. The work already done on kexec and
NUMA, for example, is sure to be of help in forking off multiple instances of
the same kernel. Actually, I had a very good discussion about the use of
kexec in the scheme I'm suggesting with Eric Biederman at the last OLS.
If you're still reading this and are interested in the actual implementation
of SMP clusters, have a look at what I'm suggesting and let me know what
you think:
http://www.opersys.com/ftp/pub/Adeos/practical-smp-clusters.ps
http://www.opersys.com/ftp/pub/Adeos/practical-smp-clusters.pdf
http://www.opersys.com/adeos/practical-smp-clusters/
Cheers,
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 514-812-4145
reply other threads:[~2003-09-05 4:07 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=3F580CCF.5010109@opersys.com \
--to=karim@opersys.com \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox