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.

On Fri, 5 Mar 1999, Richard Gooch wrote:
> Distributed shared memory is a fundamentally flawed idea. It pretends
> to be SMP when it really isn't. With SMP I can have two CPUs writing
> to the same page (different cache lines) at the same time and it's
> fast.

Two CPU's can't write to the same location of the cache at the same
time, and in DSM two processes can't write to the same page at the same
time. Same inherent limitation.

> With DSM, you've got MMU tricks to only allow one machine at a time to
> write. If one CPU writes and then the other reads, you've got shift
> the page across the network.

First time I hear being slower is a sign of being fundamentally flawed.

> With SMP, a lock is cheap. With DSM, a lock is expensive.

I guess most people know this. I would use a semaphore for
synchronization in a DSM application.

> > 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.
>
> Your analogy is broken. Multitasking has hardware support and is a
> cheap operation. DSM has no hardware support and is an expensive
> operation.

Can be done with no hardware support. Look at the Amiga OS that ran on a
little MC68000. They put support for it in the hardware because most OS
designers needed it. That's it.

> Even on machines which do have hardware support (SGIs Origin series),
> it's my understanding that getting page migration to work properly has
> been a problem.

I don't know about that case. It works properly under DIPC.

> > 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.
>
> Yeah, right. Lets rewrite the kernel in Java: it provides such nice
> abstractions.
>
> Please.

I thought you would like this approach!

> > 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.
>
> My point is that DIPC/DSM is the *wrong* abstraction. Same goes for
> MOSIX.

IMO, You're reasons are not very valid.

> > Performance seems to have been a secondary issue.
>
> Sure, in *computer science*. CS labs around the world have been
> producing new operating systems for decades, each one is more abstract
> than the ones before. Now tell me how many of them are actually used
> in the real world?

Nearly all of the things you are using now were first developed in CS
labs. Some things would catch on and some won't. In most cases
non-technical reasons are involved in a concept's wide-spread usage.

> You don't need DSM to provide a nice and easy programming environment.

DSM may not be the only way, but it sure is nice and easy to use.

> DIPC (as in: strict message-passing) is one thing. Distributed shared
> memory is another. Two nodes banging on the same page just isn't going
> to run well with DSM.

Agreed. The programmer who needs to avoid such pitfalls has to be
careful. The good thing is that DIPC will work even if the application
behaves in such ways. The programmer can always go back and improve on
his already-working app.

> No, go back and read what I said. DSM is the *wrong* abstraction. DIPC
> without the DSM it is OK (as long as the kernel isn't bloated with it:
> do it in the library).

That is your opinion, and believe me, you'll have a hard time convincing
me of that.

-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.156 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site