lkml.org 
[lkml]   [1999]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Lets get this right (WAS RE:MOSIX and kernel mods)
Date
From "Albert D. Cahalan" <acahalan@cs.uml.edu>
: No, just the person I responded to. He made an emotional appeal based
: on some kind of glorious fight against mediocrity.

Yes, and you made an emotional appeal, also not backed up with any facts,
for some features that are of very questionable usefulness. Based on my
own direct experience with DSM, as well as having reviewed multiple DSM
papers, including a Stanford PhD thesis, and having read piles of other
DSM papers, and having worked on applications which actually use DSM,
I concur with the conclusion that the former person made: DSM sucks.

And it isn't an emotional thing at all, it's simply that it doesn't work
for any real applications. Any application which can withstand the
latencies introduced by DSM can typically be trivially rewritten to
use MPI or PVM intrerfaces to accomplish the same thing, usually with
higher performance.

: Those that wrote the DSM code state that it has little impact on the
: rest of the kernel. Do you claim that they lie?

Yup, I sure do. And I also question the addition of a feature which has
been repeatedly shown to cause more problems than it solves. If you
really want DSM in the kernel, then put it into fs/dsm file system,
use mmap to create the shared memory, and extend msync() to handle your
coherency. This has been done before, using NFS as a base, and I have
a paper I can send you on it. At least that way, while you are learning
about what a bad idea this is, you are doing it in your own file system,
which is a nice self contained sandbox. If you make it work, great.
If you don't, also great because you haven't added a bunch of stuff to
the generic kernel in the process.

Even if this was a great idea, I'd ask you to do it this way - it is the
obvious right way of doing it. In fact, SunOS's VM system to file system
interface was carefully designed to allow exactly this sort of coherency
decisions to be done in the file system, not in the VM system. The VM
system presented an abstraction which did not include a coherency protocol
or guarentee. That was a property of the file system. As it should be.

: > Show me the apps which match this model.
:
: Just about any shared memory app fits, given the right run length,

Once again, show me the apps. Specific apps, show me the code to those
apps and tell me why you /know/, not why you /think/, those apps will
work on a slow DSM substrate.

Telling us that you think this will work is not very credible, especially
when you are talking to someone who is (a) a performance guy, (b) a
file systems and VM guy, (c) has worked in this area, and (d) has read
a bizillion papers on the topic, all of which eventually conclude that
it is a bad idea.

It would be a lot different if it were just my opinion against your
opinion, that's just two idiots arguing, to coin a phrase. So far,
this appears to be my experience against your opinion, which leaves
you in a shaky position. I'm more than happy to be proven wrong, that
would mean that I have learned something which is always a welcome event.
But I'm convinced through multiple experiences that it is unlikely that
you can prove me wrong, so I'm asking you to actually do so instead of
just asserting that you can. I hope that you take this the right way -
I want to be surprised, but given the track record of DSM, the right
thing here is to push back very hard and request real hard facts rather
than theories.

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.036 / U:0.992 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site