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.
The thing is that there are lots of neat applications for this sort of
thing in the kernel as well.

The fact is that there is no way to make a program (that has been written
ignorant of the type of machine it will be run on) faster just by adding
some kernel module or kernel tricks to make it run the processes on other
machines. You have to write the program thinking of how to parallelize
sections of code that don't have data-dependency issues. This sort of
thing is done in threaded programming as well but in a different way
because of the nature of threads. Parallelizing code is done in any
application where performance is an issue.

All I'm suggesting is that there are some applications that fit the model
of many machines working in harmony and coordinating their actions than
one machine trying to do it all. And I further suggest that if there are
ways to do this in a uniform way through a sufficiently tailored
abstraction layer, then making it a part of the kernel, even as a loadable
module, is worth a bit of thought.

Programmers have enough to worry about without trying to add a layer of
complexity to their code. A good toolkit that did the work for them and
worked within the framework for process management and interprocess
signalling and communication would be of great value.

Of course, if you don't that stuff you can just compile a kernel without
them... :)


Richard Gooch wrote:

> Richard Solis writes:
> > I couldn't agree more.
> >
> > But I do think there is value there because DIPC and friends could
> > be very valuable as tools for developing applications that work
> > better in a distributed manner. If each section of code (thread,
> > process) can operate within the framework that DIPC, et al. provide
> > then there is a good argument for providing that functionality as an
> > integrated part of the OS where things like filesystems and process
> > management and signalling can be coordinated with the help of the
> > kernel.
>
> Actually, I don't think we really agree. My view is that using
> DIPC/MOSIX encourages bad programming and will hardly ever lead to
> efficient parallel applications. Now if someone wants to write a user
> space layer that gives them such a programming model, that's fine by
> me.
>
> But I'd object to even one nanosecond of extra latency or one byte of
> kernel bloat to (exclusively) support such schemes, because I think
> they're flawed. It's the same reason we don't want STREAMS in the
> kernel. It's a flawed concept and it shouldn't bloat the kernel or
> kill performance for sensible networking.
>
> Now, if DIPC/MOSIX requires a kernel module and perhaps some system
> calls, I don't mind if they are allocated some slots in the syscall
> table (just like we did for STREAMS). But anything else should stay
> out of the kernel.
>
> Regards,
>
> Richard....


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