lkml.org 
[lkml]   [1999]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

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