Messages in this thread | | | From | (Larry McVoy) | Subject | Re: Lets get this right (WAS RE:MOSIX and kernel mods) | Date | Sat, 06 Mar 1999 12:33:17 -0800 |
| |
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/
| |