> Good day to everyone following this thread.
Good day to you too.
> I find this discussion of clustering quite interesting in light of
> what my research associate has been telling me the last week. We are
> currently running one of our research clusters over switched Fast
> Ethernet. My RA and one of our campus researchers have been working
> on parallelizing a 3-dimensional soils model using C++ and MPI. They
Clearly you have the resources and motivation to do whatever you can
to get the very best performance out of the system.
> That being said I think that we as a community need to consider the
> whole issue very carefully. I have been working with Linux for a long
> time (Hi Larry) as some of the 'old-timers' will attest. We need to
Yes.
> forge ahead with innovation and excellence since that is what has
For a kernel, "excellence" includes providing support for a wide
variety of user software. That includes yucky stuff like DOSEMU,
MP3 players that don't skip under heavy system load, and mmap()
for simple file access.
> This is going to require that we deal with issues in a manner which is
> much different than in the past. If something gets put into the
> kernel, even as a compile option, the suggestion is that this has been
> given the imprimatur of Linus and the community. Both entities which
> have gained a lot of respect and credibility in the last several
> weeks/months. Developers and others will take the presence of code in
> the 'official' tree as an affirmation of the features usefulness and
There are many ways to judge "usefulness". There is no single best
solution for most interesting problems.
It seems to me that people who work hard to get the very best
performance have trouble understanding why anyone would settle
for less. Why doesn't everybody use a dvorak keyboard? The dvorak
keyboard is clearly superior to the common junk. I hope everyone
arguing against DIPC uses one.
You have chosen mediocrity if you do not use dvorak keyboard layout.
I'd love to see a justification for non-dvorak keyboards which does
not also apply to DIPC. The traditional layout is kernel bloat too,
unless a newly loaded layout overwrites the old one.
> will begin building application dependency on it. Once this happens
> there is no going back so we must make fundamental architecture
> decisions with great prudence.
Certainly. From a kernel viewpoint, DIPC is not a fundamental architecture
decision. It is only an extension to the existing SysV IPC code.
> What Larry is asking for is not unreasonable, proof by performance
> measurement.
No, it is unreasonable. Performance is only one of many ways to judge
a feature. Obviously DIPC is not for him or you.
> I don't think that anyone would suggest for a minute
> that Linus would not include something that amply demonstrated
> superiority in a test cluster.
Yes. We may disagree about how one determines superiority.
> To sort of put my money where my mouth is if there are any groups that
> want to pursue 'Darwinism' in the field of kernel cluster development
> let me know and I can provide testbed time for measurements and tests.
If you have computer time left over, maybe you didn't need to optimize
so much. :-)
I would be happy to see several DIPC implementations benchmarked
against each other, but it is rather pointless to benchmark DIPC
against something else. Everybody agrees what the result will be.
I was truly surprised by the DIPC ease-of-use today. The worst part
by far is setting up the new kernel and rebooting. Changes to the
application code are trivial. You could use a perl one-liner for it.
Conversion to MPI is far more complicated.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/