Messages in this thread | | | Date | Thu, 4 Mar 1999 10:52:15 -0600 (CST) | From | Kamran Karimi <> | Subject | Re: MOSIX and kernel mods. |
| |
Richard Gooch wrote:
>Going hopefully more on-topic, I don't think MOSIX matters anyhow. I'm >not convinced of the merit of the idea in the first place. If you want >"nice" clustering support, you're probably better off with DIPC >anyway, keeping more of it in user space (but still not all).
In DIPC's case, the kernel used to handle the IPC in a single computer. If you want a very high degree of transparency, you have to offer the new distributed functionality from the kernel.
Although one may be able to use link libraries to move some stuff out of the kernel, DIPC's Distributed Shared Memory has to remain there, as it requires direct manipulation of the processor's Memory Management Unit (tools like mprot don't do what DIPC needs).
>And I'm not even convinced about the DIPC model either. I think trying >to pretend a networked cluster of machines is really a single happy >machine with lots of nodes is fundamentally flawed.
Interesting. This is like saying it is wrong to let the OS do task-switching and create the illusion that more than one task are running, while in reallity there is only one CPU. Why not make the programmers deal with such issues themselves? They have to make sure their programs stop at the specified time intervals so that other apps get a chance to run.
And why stop here? Why not let them handle their own memory managment? After all, they know more about their memory needs than the OS! Let them use overlaying to save parts of their memory space they _know_ will not be used in near future out to a hard disk. This will improve performance because the OS is too dumb to make a good decision in many cases. The possibilities are limitless here.
The trend in computer science has been to add more and more abstraction layers, so as to reduce the complexity of the application development and maintanance times. Performance seems to have been a secondary issue.
>The right way >(IMNSHO) is to provide a flexible and lightweight API to support >communications (in user space), and write your application *knowing* >you're running on a networked cluster.
IMNSHO, _most_ people prefer ease of programming to performance issues. Now, I understand if an embedded system developer has to deal with code speed and size issues, but it seems very selfish to me to see such a person insisting that all the other people should stop using high level development tools like Visual Basic because they create very big and slow code.
Apparently you have no problem with automatic task switching and memory managemnt, how come you think adding another abstraction layer would be wrong? My guess (and I could be wrong) is that you are used to employing message passing for distributed programming. You have no problem with that, and adopting an easier programming model (like DIPC) seems unnecessary to you.
>Any abstraction that attempts to hide the immutable fact that >inter-node latency is high and bandwidth is low is a *bad* >abstraction. It lulls the programmer into thinking they're writing >efficient code. Local nodes and remote nodes *should* be treated >differently, because they *are* different.
What hiding? No matter what programming interface you use (explicit message passing like PVM, or implicit message passing like DIPC), you have to deal with the fact that crossing the network is slow. This is obvious. DIPC does not hide this fact. It lets the programmer do data exchange in some familiar ways, so he or she won't have to learn a new set of APIs. Execute that DIPC program in a single computer, and it runs at full speed. Run it on a network, and things will probably slow down. In short: We run in a cruel world. Do we want to make things easier on ourselves or not??
Your statment above is like someone advocating the exclusive use of assembly language now a days. Inspite of all the advances in networking, Distributed Programming has not become popular because of a lack of easy to use programming model. Only scientists and some other "power users" have ruled here. Given a simpler programming method, I think these people will become a small minority among the distributed programmers.
>IMO MOSIX/DIPC is the wrong approach.
Depends on the application requirements. many applications wouldn't care about performance. Some do, and they could use whatever method best suits their needs.
Putting DIPC inside the kernel will enable many programmers to develop distributed applications that we would otherwise not see. DIPC can be turned off any time, and adds very little to the kernel. Given that it is a compile-time option, you can even leave it out of the kernel completely. I'd say this is a small price to pay for a whole lot of functionality.
>I'll now stand back and hold out a few marshmallows...
Keep some for me :-)
-Kamran
- 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/
| |