Will Mosix go into the standard kernel?

zbrown at tumblerings.org zbrown at tumblerings.org
Wed Feb 28 18:37:09 PST 2001


On Wed, Feb 28, 2001 at 06:06:37PM -0500, Daniel Ridge wrote:
> 
> Fellow Beowulfers,
> 
> I have yet to hear a compelling argument about why any of them should 
> go into the standard kernel -- let alone a particular one or a duck of a
> compromise.
> 
> The Scyld system is based on BProc -- which requires only a 1K patch to
> the kernel. This patch adds 339 net lines to the kernel, and changes 38
> existing lines.
> 
> The Scyld 2-kernel-monte kernel inplace reboot facility is a 600-line
> module which doesn't require any patches whatsoever.
> 
> Compare this total volume to the thousands of lines of patches that
> RedHat or VA add to their kernel RPMS before shipping. I just don't see 
> the value in fighting about what clustering should 'mean' or picking
> winners when it's just not a real problem.

Where is the value in a bunch of incompatible alternatives that have to
be laboriously ported to each new kernel version, the patches growing ever
larger as the official sources gradually diverge?

I see your point about not wanting to standardize too quickly, and I agree. But
what is the harm in *talking* about it? Why not find out if some standard kernel
clustering API could be useful, instead of just rejecting the idea out of hand?

Maybe it's my fault as the originator of this thread, for asking if _MOSIX_
would ever be included. I certainly don't think MOSIX should be favored over
other clustering implementations, it just happens to be the one I think about
most often.

I think one compelling argument in favor of including some kind of clustering
API in Linux is to encourage folks to use it and hack on it. Then we can
spawn Wintermute and become blind slaves to its awesome power.

> 
> Scyld is shipping a for-real commercial product based on BProc and
> 2-kernel-Monte and our better-than-stock implementation of LFS and and
> we're not losing any sleep over this issue.
> 
> I think we should instead focus our collective will on removing things
> from the kernel. For years, projects like ALSA, pcmcia-cs, and VMware
> have done an outstanding job sans 'inclusion' and we should more
> frequently have the courage to do the same. RedHat and other linux vendors
> have demonstrated ably that they know how to build and package systems
> that draw together these components in an essentially reasonable way. 

Where do you draw the line? Maybe the developers should take SMP out of the
kernel, so the different vendors can all implement their favorite versions
without any ducks of compromise. (and don't tell me there is only one
universally accepted best way to implement SMP)

Be well,
Zack

> 
> Regards,
> 	Dan Ridge
> 	Scyld Computing Corporation
> 
> On Tue, 27 Feb 2001, Rik van Riel wrote:
> 
> > On Tue, 27 Feb 2001, David L. Nicol wrote:
> > 
> > > I've thought that it would be good to break up the different
> > > clustering frills -- node identification, process migration,
> > > process hosting, distributed memory, yadda yadda blah, into
> > > separate bite-sized portions.
> > 
> > It would also be good to share parts of the infrastructure
> > between the different clustering architectures ...
> > 
> > > Is there a good list to discuss this on?  Is this the list?
> > > Which pieces of clustering-scheme patches would be good to have?
> > 
> > I know each of the cluster projects have mailing lists, but
> > I've never heard of a list where the different projects come
> > together to eg. find out which parts of the infrastructure
> > they could share, or ...
> > 
> > Since I agree with you that we need such a place, I've just
> > created a mailing list:
> > 
> > 	linux-cluster at nl.linux.org
> > 
> > To subscribe to the list, send an email with the text
> > "subscribe linux-cluster" to:
> > 
> > 	majordomo at nl.linux.org
> > 
> > 
> > I hope that we'll be able to split out some infrastructure
> > stuff from the different cluster projects and we'll be able
> > to put cluster support into the kernel in such a way that
> > we won't have to make the choice which of the N+1 cluster
> > projects should make it into the kernel...
> > 
> > regards,
> > 
> > Rik
> > --
> > Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml
> > 
> > Virtual memory is like a game you can't win;
> > However, without VM there's truly nothing to lose...
> > 
> > 		http://www.surriel.com/
> > http://www.conectiva.com/	http://distro.conectiva.com/
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Beowulf mailing list, Beowulf at beowulf.org
> > To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
> > 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
-- 
Zack Brown





More information about the Beowulf mailing list