Path: bga.com!news.sprintlink.net!howland.reston.ans.net!pipex!
sunsite.doc.ic.ac.uk!bay.cc.kcl.ac.uk!sutton
Newsgroups: comp.os.linux.development
Subject: Linux 2 - The Microkernel
Message-ID: <1994Nov30.110346.5280@bay.cc.kcl.ac.uk>
From: sut...@dcs.kcl.ac.uk (Al Sutton)
Date: 30 Nov 94 11:03:46 GMT
Nntp-Posting-Host: helium.dcs.kcl.ac.uk
X-Newsreader: TIN [version 1.2 PL2]
Lines: 25
There has been a lot of talk about a version 1.2 of Linux (someone even
talked about a 1.3), and there has been a bit of talk about a micorkernel
version of Linux. Putting these together I have come up with the following
suggestion:-
Linux versions 1.x.x
---------------------
These carry on from the current version of Linux, development will roll on
as it has now with versions 1.2, 1.3, 1.4, ....
Linux version 2.x.x
-------------------
This will be a "new" version of linux - The talked about microkernel
version. This would either start from scratch, or would take exsisting
kernel source and microkernelise it.
I'll admit I've never done any work with the Linux kernel, and so this is
only an idea, so post your follow-ups here.
Al.
Newsgroups: comp.os.linux.development
Path: bga.com!news.sprintlink.net!pipex!uunet!zib-berlin.de!math.fu-berlin.de!
leitner
From: leit...@inf.fu-berlin.de (Felix von Leitner)
Subject: Re: Linux 2 - The Microkernel
Message-ID: <M2WUBVWI@math.fu-berlin.de>
Sender: n...@math.fu-berlin.de (Math Department)
Nntp-Posting-Host: puma.inf.fu-berlin.de
Organization: Free University of Berlin, Germany
References: <1994Nov30.110346.5280@bay.cc.kcl.ac.uk>
Date: Wed, 30 Nov 1994 14:45:16 GMT
Lines: 63
sut...@dcs.kcl.ac.uk (Al Sutton) writes:
>There has been a lot of talk about a version 1.2 of Linux (someone even
>talked about a 1.3), and there has been a bit of talk about a micorkernel
>version of Linux. Putting these together I have come up with the following
>suggestion:-
What is the deal with the microkernel, besides Mr. Tanenbaum becoming happy
? You don't need a microkernel to receive eternal happyness, trust me. This
is just another buzzword.
You can see how much you need the microkernel be having a look at some
remarks about it :
"It has been showed that microkernel systems can be nearly as fast as
monolithic systems". Which means to me they took the MACH kernel, optimized
it to the brink and compared it to some losing OS like VMS or something ;)
Do YOU want a microkernel just to have a microkernel (the user won't notice
!) and sacrifice some 10 percent performance for it ? I wouldn't.
>Linux versions 1.x.x
>---------------------
>These carry on from the current version of Linux, development will roll on
>as it has now with versions 1.2, 1.3, 1.4, ....
It's confusing enough the way it is. I'd rather have 1.x for the regular
version and 1.x d for the hackers' heaven version. Newbies are confused by
the unconventional numbering scheme !
>This will be a "new" version of linux - The talked about microkernel
>version. This would either start from scratch, or would take exsisting
>kernel source and microkernelise it.
Microkernel is a neat idea some researchers had, but it hasn't proven better
than a monolithic kernel so far. The microkernel has some advantages on
multiprocessor machines and on unstable kernels, because the kernel parts
are protected from each other. But if the file system crashes it doesn't
help that the rest of the system does not crash I think !
>I'll admit I've never done any work with the Linux kernel, and so this is
>only an idea, so post your follow-ups here.
Well, never propose something you haven't calculated. This is far too much
work to be justified by the gains if Linux stays a monoprocessor system.
I'd REALLY like a multiprocessor Linux for some cheap scalable processor,
say the PowerPC or i860 (ok, maybe the pestillencium) or the Alpha or
whatever. But with only one processor you don't need a microkernel.
The WIN of Linux compared to other OSes is it's speed. I don't want to
sacrifice any part of it for some research toy like a mirokernel.
If the GNU hurd is finished some day (hehehe) we can talk again.
Felix
PS: Is NT modelled after the Hurd ? It's vaporware, too ;)
--
If Rush Limbaugh doesn't need a disclaimer, neither do I.
"Who is General Failure and why is he reading my hard disk ?"
Microsoft spel chekar vor sail, worgs grate !!
Path: bga.com!news.sprintlink.net!pipex!uunet!boulder!csnews!
frisbee.cs.Colorado.EDU!drew
From: d...@frisbee.cs.Colorado.EDU (Drew Eckhardt)
Newsgroups: comp.os.linux.development
Subject: Re: Linux 2 - The Microkernel
Date: 30 Nov 1994 17:13:04 GMT
Organization: University of Colorado, Boulder
Lines: 63
Message-ID: <3bibr0$jqv@csnews.cs.Colorado.EDU>
References: <1994Nov30.110346.5280@bay.cc.kcl.ac.uk>
NNTP-Posting-Host: frisbee.cs.colorado.edu
In article <1994Nov30.110346.5...@bay.cc.kcl.ac.uk>,
Al Sutton <sut...@dcs.kcl.ac.uk> wrote:
>There has been a lot of talk about a version 1.2 of Linux (someone even
>talked about a 1.3), and there has been a bit of talk about a micorkernel
>version of Linux. Putting these together I have come up with the following
>suggestion:-
>
>
>Linux versions 1.x.x
>---------------------
>
>These carry on from the current version of Linux, development will roll on
>as it has now with versions 1.2, 1.3, 1.4, ....
>
>
>Linux version 2.x.x
>-------------------
>
>This will be a "new" version of linux - The talked about microkernel
>version. This would either start from scratch, or would take exsisting
>kernel source and microkernelise it.
The only reasons to implement a micro kernel are
1. To facilitate a distributed kernel on symetric multi-processor
machines.
Given that none of the developers have SMP machines,
I don't think it will happen. Especially since the
path of least resistance to implement a micro-kernel
is to start with a mutex arround the whole kernel,
and go with progressively smaller critical regions
(ie, Solbourne's SunOS based OS/MP).
2. To placate your marketing department. For some odd reason,
marketing departments are under the mistaken impression
that 'micro kernels' are some how smaller than
macro kerneles. There's no truth to it.
The reasons not to implement a micro kernel are
1. A propperly designed microkernel is no faster, slower, bigger,
smaller, etc. than a properly designed macro kernel. Ie,
potentially man years of effort could be exerted, for no
net gain.
2. The loss of the multi-threaded nature inherent in a macro kernel
3. Additional context switches
You'll get features that you get from many micro kernels, like loadable
device drivers (Ie, Eric just made the SCSI subsystem loadable), but
architecturally, I don't think you'll seen mainstream Linux go micro
kernel.
(There is a project to put Linux on top of Mach 3, sort of like the BSD
single server, but I don't think it will be too popular due to the
lesser hardware support of Mach, and the fact that it should prove
slower than native Linux).
--
"Don't tread on me"
Path: bga.com!news.sprintlink.net!mhv.net!metro.atlanta.com!hood.paros.com!
hood.paros.com!collins
From: coll...@zeke.paros.com (Jeffery A. Collins)
Newsgroups: comp.os.linux.development
Subject: Re: Linux 2 - The Microkernel
Date: 30 Nov 1994 20:00:11 GMT
Organization: Paros, Inc.
Lines: 22
Message-ID: <COLLINS.94Nov30150011@zeke.paros.com>
References: <1994Nov30.110346.5280@bay.cc.kcl.ac.uk>
NNTP-Posting-Host: zeke.paros.com
In-reply-to: sutton@dcs.kcl.ac.uk's message of 30 Nov 94 11:03:46 GMT
Al Sutton writes:
>>Linux version 2.x.x
>>-------------------
>>
>>This will be a "new" version of linux - The talked about microkernel
>>version. This would either start from scratch, or would take exsisting
>>kernel source and microkernelise it.
>>
Why would anyone every want a microkernel version of Linux (or any
operating system for that matter)? I've spent extensive time taking a
good, working integrated kernel and "microkernelizing" it. All you
end up with is something with the same functionality that is more
complicated and runs slower.
Jeff Collins
--
==============================================================================
Jeff Collins Email: coll...@paros.com
President Phone: (404) 874-5122
Paros Software, Inc FAX: (404) 874-8171
Path: bga.com!news.sprintlink.net!howland.reston.ans.net!gatech!
bloom-beacon.mit.edu!uhog.mit.edu!news.mathworks.com!newshost.marcam.com!
charnel.ecst.csuchico.edu!olivea!koriel!newsworthy.West.Sun.COM!
cronkite.Central.Sun.COM!koppel.East.Sun.COM!uk-usenet.uk.sun.com!usenet
From: al...@coyote.uk.sun.com (Alec Muffett)
Newsgroups: comp.os.linux.development
Subject: Re: Linux 2 - The Microkernel
Date: 30 Nov 1994 21:04:06 GMT
Organization: The unconfigured xvnews people
Lines: 88
Message-ID: <3bipc6$dl2@uk-usenet.uk.sun.com>
References: <COLLINS.94Nov30150011@zeke.paros.com>
Reply-To: al...@coyote.uk.sun.com
NNTP-Posting-Host: coyote.uk.sun.com
X-Newsreader: xvnews 2.3 Beta PL7, use only for testing please.
In article <COLLINS.94Nov30150...@zeke.paros.com>, coll...@zeke.paros.com
(Jeffery A. Collins) writes:
> Al Sutton writes:
> >>Linux version 2.x.x
> >>This will be a "new" version of linux - The talked about microkernel
> >>version. This would either start from scratch, or would take exsisting
> >>kernel source and microkernelise it.
> Why would anyone every want a microkernel version of Linux (or any
> operating system for that matter)?
...because software engineers are generally sheep who are driven by
trendy buzzwords and the requirement to supply "what the market wants".
Unfortunately, the only reason that the market knows what it wants is
because it is told what it wants by an equally trend-driven media and
clueless marketing droids.
- Hence, everyone knows what they want, but not what they *need*. The
packaging/interface (eg: a GUI) for the required functionality (eg: a
spreadsheet) becomes more important than what the functionality
itself.
Hence: (dialogue)
We must have a microkernel so that we can have dynamic device driver
loading and lightweight processes!
Why do you want dynamic driver loading ?
Because it uses resources more efficiently!
What, you mean that because it requires more memory
(driver code + generic module interface) than a static driver,
it's making more efficient use of hardware ?
Yes!... well, maybe... Ummm.
OK, so, why do you want LWPs ?
So that we can write (say) lightweight multithreaded
window managers for X.
Are you going to write this windowmanager then ?
No.
Do you know anyone who is going to write one ?
No.
Would a WM using threads and LWPs be portable
and backwards compatible ?
Eventually... well, maybe... er, no.
What window manager do you use now ?
FVWM.
Are you going to give it up when this new threaded WM comes along ?
No.
So you're going to add LWPs to the kernel to support this one
threaded application which you're not even going to use ?
Yes.
So why make Linux a microkernel OS ?
Because people want the functionality !
...- and so forth.
>I've spent extensive time taking a
> good, working integrated kernel and "microkernelizing" it. All you
> end up with is something with the same functionality that is more
> complicated and runs slower.
Hear, hear.
---
Alec Muffett (A Goret is for life, not just for Christmas)
Sun Microsystems UK (define-key global-map "\C-m" `save-buffers-kill-emacs)
Network Security Group
(speaking for himself, not his employers)
Path: bga.com!news.sprintlink.net!howland.reston.ans.net!pipex!bnr.co.uk!
corpgate!bcarh189.bnr.ca!nott!torn!fonorola!achilles!achilles!not-for-mail
From: pjlah...@achilles.net (Paul JY Lahaie)
Newsgroups: comp.os.linux.development
Subject: Re: Linux 2 - The Microkernel
Date: 2 Dec 1994 13:07:59 -0500
Organization: Achilles Online Services
Lines: 31
Message-ID: <3bnnpv$184@zeus.achilles.net>
References: <1994Nov30.110346.5280@bay.cc.kcl.ac.uk> <M2WUBVWI@math.fu-berlin.de>
NNTP-Posting-Host: zeus.achilles.net
In article <M2WUB...@math.fu-berlin.de>,
Felix von Leitner <leit...@inf.fu-berlin.de> wrote:
>You can see how much you need the microkernel be having a look at some
>remarks about it :
>
> "It has been showed that microkernel systems can be nearly as fast as
>monolithic systems". Which means to me they took the MACH kernel, optimized
>it to the brink and compared it to some losing OS like VMS or something ;)
>
>Do YOU want a microkernel just to have a microkernel (the user won't notice
>!) and sacrifice some 10 percent performance for it ? I wouldn't.
I'm writing this from a QNX 4.2 machine dialed into a Linux machine. On
comparable hardware, the QNX machine isn't 10% slower (trust me). The big
challenge is the optimizing, and the microkernel model, but a microkernel
can be as fast as Linux.
>Microkernel is a neat idea some researchers had, but it hasn't proven better
>than a monolithic kernel so far. The microkernel has some advantages on
>multiprocessor machines and on unstable kernels, because the kernel parts
Also, since the kernel parts are abstracted (ie: they would call some
form of query_server_msg_port, send/recv), you can have servers reside
across network links, etc.. Great for distributed environments.
- Paul
--
Paul JY Lahaie Internet: pjlah...@achilles.net
Achilles Internet
Director of Technical Operations
Path: bga.com!news.sprintlink.net!howland.reston.ans.net!europa.eng.gtefsd.com!
ulowell!news.uml.edu!jrichard
From: jrich...@sable.uml.edu (John Richardson)
Newsgroups: comp.os.linux.development
Subject: Re: Linux 2 - The Microkernel
Date: 02 Dec 1994 23:03:52 GMT
Organization: University of Massachussets - Lowell
Lines: 26
Message-ID: <JRICHARD.94Dec2180352@sable.uml.edu>
References: <1994Nov30.110346.5280@bay.cc.kcl.ac.uk> <M2WUBVWI@math.fu-berlin.de>
<3bnnpv$184@zeus.achilles.net>
NNTP-Posting-Host: sable.uml.edu
In-reply-to: pjlahaie@achilles.net's message of 2 Dec 1994 13:07:59 -0500
In article <3bnnpv$...@zeus.achilles.net> pjlah...@achilles.net (Paul JY Lahaie)
writes:
I'm writing this from a QNX 4.2 machine dialed into a Linux machine. On
comparable hardware, the QNX machine isn't 10% slower (trust me). The big
challenge is the optimizing, and the microkernel model, but a microkernel
can be as fast as Linux.
Does QNX actually use seperate processes or loadable modules? Or
something different?
Also, since the kernel parts are abstracted (ie: they would call some
form of query_server_msg_port, send/recv), you can have servers reside
across network links, etc.. Great for distributed environments.
Yup, good for clusters etc... which is probably why Dec decided to
run with OSF/1...
It's probably true that when we all have 4-processor 300Mhz Alphas on our
desks we'll live with the microkernels since they make the software
engineering easier from the kernel subsystem point of view. Until
then, I'm happy with my 486-66 running Linux. :)
--
John Richardson
jrich...@cs.uml.edu
Path: bga.com!news.sprintlink.net!howland.reston.ans.net!usc!news.isi.edu!
not-for-mail
From: rog...@drax.isi.edu (Craig Milo Rogers)
Newsgroups: comp.os.linux.development
Subject: Re: Linux 2 - The Microkernel
Date: 2 Dec 1994 21:27:08 -0800
Organization: USC Information Sciences Institute
Lines: 35
Message-ID: <3bovjc$18t@drax.isi.edu>
References: <COLLINS.94Nov30150011@zeke.paros.com>
<3bipc6$dl2@uk-usenet.uk.sun.com>
NNTP-Posting-Host: drax.isi.edu
>We must have a microkernel so that we can have dynamic device driver
>loading and lightweight processes!
If I may be permitted to continue to reason by analogy to
ancient history, DEC's RSX-11D/M operating systems had dynamic device
drivers and tasks (lightweight processes) on the PDP-11 in the
mid-to-late '70s. Was it a microkernel OS?
My response is that it may have been one, even though this was
before "microkernel" was coined. For example, consider its size: alot
smaller than "modern" OS kernels, certainly a lot smaller than many
versions of Mach. On the other hand, its treatment of some system
services, such as filesystems, was not fully in line with modern
microkernel design.
Now, consider that Linux already supports (to varying degrees)
its native interpretation of POSIX, iBCS2, DOSEMU, and WINE, it is
apparent that Linux supports multiple personalities, another
characteristic of microkernels according to the sales literature.
Dynamically-loaded kernel modules are available. Kernel threads might
me coming.
I speculate that Linux is in the process of evolving *into* a
microkernel.
The major obstacles are addressing the issues of multiple
processors in a single physical memory space, and multiple processes
in a single virtual address space. If these can be accomplished, I
see no reason why Linux cannot become a microkernel. Of course,
adding SMP support to an existing operating system has traditionally
been difficult. But given the large programmer community to which
Linux has access, and the combination of open development and strong
editorial control, it may be achievable.
Craig Milo Rogers
Path: bga.com!news.sprintlink.net!hookup!news.kei.com!sol.ctr.columbia.edu!
caen!usenet.coe.montana.edu!bsd.coe.montana.edu!nate
From: n...@bsd.coe.montana.edu (Nate Williams)
Newsgroups: comp.os.linux.development
Subject: Re: Linux 2 - The Microkernel
Date: 5 Dec 1994 04:21:28 GMT
Organization: Montana State University, Bozeman Montana
Lines: 123
Message-ID: <3bu4g8$qsv@pdq.coe.montana.edu>
References: <1994Nov30.110346.5280@bay.cc.kcl.ac.uk>
<3bibr0$jqv@csnews.cs.colorado.edu>
NNTP-Posting-Host: bsd.coe.montana.edu
In article <3bibr0$...@csnews.cs.colorado.edu>,
Drew Eckhardt <d...@frisbee.cs.Colorado.EDU> wrote:
[ With all respect to Drew's contributions, this is begging to be followed
up with. ]
>The only reasons to implement a micro kernel are
>
> 1. To facilitate a distributed kernel on symetric multi-processor
> machines.
>
> Given that none of the developers have SMP machines,
> I don't think it will happen. Especially since the
> path of least resistance to implement a micro-kernel
> is to start with a mutex arround the whole kernel,
> and go with progressively smaller critical regions
> (ie, Solbourne's SunOS based OS/MP).
With multi-processor Pentium boxes becoming VERY common, ignoring SMP is
simply foolish. Within the next 5 years multi-processor machines will
become commonplace on the desktop IMHO. It is *MUCH* more difficult to
implement SMP with macro vs. microkernels.
> 2. To placate your marketing department. For some odd reason,
> marketing departments are under the mistaken impression
> that 'micro kernels' are some how smaller than
> macro kerneles. There's no truth to it.
I think this is no longer the case. In most places where Linux and
micro-kernels are developed, it is understood that micro-kernel means
micro-functionality, where most of the processing is NOT done in the
kernel but in separate processes.
Some more advantates, all assuming a correctly designed u-kernel.
3. It's easier to develop and research new file system types, since you
can debug them as a user process. This goes for other OS research as
well, such as schedulers, new networking stacks, and all sorts of other
fun kernel-like features
4. Micro-kernels *force* a layer of abstraction on the programmer which cause
them to write more maintainable code. Bad programmers will always
write good code, but good programmers are lead in better directions. It's
very easy to write event driven good in a micro-kernel.
5. There is a standard API that allows for ease of understanding in a
micro-kernel. A monolithic kernel becomes too large for one person
to understand completely (though I'm sure Linus is doing a pretty
fair job of it.)
6. The kernel can be 'scaled' for embedded applications easier. For
many applications, there is no need for a FS or networking. This
can be accomplished via loadable kernel modules somewhat in a
monolithic kernel, but it doesn't works as well.
{ Taking a stab at the last one }
7. Micro-kernels seem to make it easier to do Real-Time support. (Most
of the real-time stuff I've seen is implemented on micro-kernels.)
>The reasons not to implement a micro kernel are
>
> 1. A propperly designed microkernel is no faster, slower, bigger,
> smaller, etc. than a properly designed macro kernel. Ie,
> potentially man years of effort could be exerted, for no
> net gain.
Why was Linux written in the first place? There already existed plenty
of unixes for the x86, so plenty of man years of effort have been
exerted already. ;)
It was done Linus wanted to. Why discourage folks from attempting to do
it. This is just plain silly. The above advantages are enough to
justify writing just for the fun of it.
> 2. The loss of the multi-threaded nature inherent in a macro kernel
Actually, with SMP and Real-Time stuff using micro-kernels, I don't see
where you get this from. Please expound.
> 3. Additional context switches
Since context switches happen faster (if properly designed) in a
micro-kernel my assertion is that the overall context in a micro-kernel
is no worse and possibly better than a standard macro-kernel. The
advantage is that it's easier to write better code in a micro-kernel.
>You'll get features that you get from many micro kernels, like loadable
>device drivers (Ie, Eric just made the SCSI subsystem loadable), but
>architecturally, I don't think you'll seen mainstream Linux go micro
>kernel.
That may be true, but what gain is there from discouraging folks from
moving in that direction?
>(There is a project to put Linux on top of Mach 3, sort of like the BSD
>single server, but I don't think it will be too popular due to the
>lesser hardware support of Mach, and the fact that it should prove
>slower than native Linux).
This is true, but the advantages of building a micro-kernel Linux will
be seen in the future, and not directly. If speed were the only issue
you'd still be running 0.96, but people want more features and more
stuff. Also, with the resources of the Linux folks working on a
multi-threaded Linux/Mach kernel I imagine some of the bottlenecks would
be attacked in short time. :)
Finally, given the popularity of Linux, I suspect that if Linux moved
toward a micro-kernel design hardware support (if you mean device
drivers) would be quick to follow. And there is the immediate benefit
of multi-platform support that Mach would buy you. Mach runs on a lot
more platforms than Linux does today.
Just my .02 worth,
Nate
--
n...@bsd.coe.montana.edu | FreeBSD dude and all around tech.
n...@cs.montana.edu | weenie.
work #: (406) 994-4836 | Unemployed, looking for permanant work in
home #: (406) 586-0579 | CS/EE field.
Newsgroups: comp.os.linux.development
Path: bga.com!news.sprintlink.net!howland.reston.ans.net!cs.utexas.edu!
utnut!torn!uunet.ca!uunet.ca!xwing!nick
From: n...@xwing.xwing.org (Nick Busigin)
Subject: Re: Linux 2 - The Microkernel
X-Newsreader: TIN [version 1.2 PL2]
Organization: X-Wing BBS
Message-ID: <1994Dec5.051622.6997@xwing.xwing.org>
References: <1994Nov30.110346.5280@bay.cc.kcl.ac.uk>
<M2WUBVWI@math.fu-berlin.de> <JRICHARD.94Dec2180352@sable.uml.edu>
Date: Mon, 5 Dec 1994 05:16:22 GMT
Lines: 63
John Richardson (jrich...@sable.uml.edu) wrote:
: In article <3bnnpv$...@zeus.achilles.net> pjlah...@achilles.net (Paul JY Lahaie)
writes:
: I'm writing this from a QNX 4.2 machine dialed into a Linux machine. On
: comparable hardware, the QNX machine isn't 10% slower (trust me). The big
: challenge is the optimizing, and the microkernel model, but a microkernel
: can be as fast as Linux.
: Does QNX actually use seperate processes or loadable modules? Or
: something different?
QNX allows you to do both. You can build a loadable module or specify
what O.S. (and other processes) you want to load at boot time.
You can start and stop processes that provide O.S. services at any time.
It's really very configurable and doesn't require recompiling or relinking
the kernel.
: Also, since the kernel parts are abstracted (ie: they would call some
: form of query_server_msg_port, send/recv), you can have servers reside
: across network links, etc.. Great for distributed environments.
: Yup, good for clusters etc... which is probably why Dec decided to
: run with OSF/1...
Not just clusters. I develop real-time app's under QNX for factory floor
applications. I find the network transparency provided by QNX's message
passing a real plus when developing distributed applications. And as
far as speed, QNX is fast. I've done some benchmarking of QNX and found
it really flies when it comes to context switching , interrupt latency,
task pre-emption, and inter-task communication (local and network wide).
And by the way, QNX was a micro-kernel message passing O.S. in commercial
use back around 1984 - way before "micro-kernel" was a marketing buzz word.
: It's probably true that when we all have 4-processor 300Mhz Alphas on our
: desks we'll live with the microkernels since they make the software
: engineering easier from the kernel subsystem point of view. Until
: then, I'm happy with my 486-66 running Linux. :)
QNX makes my life easier not just from a kernel subsystem point of view,
but from the point of view of writing any distributed applications. The
beauty of a message passing architecture is that the programmer does
not need to know in advance whether the processes that comprise his
systems will run on the same processor or will be distributed over
a network since the O.S. looks after routing the messages. That makes
for scalability that just isn't as easily attainable with a more
traditional architecture such as that of Linux.
Getting back to the question of whether Linux should be re-written
as a micro-kernel? No way! It works great just the way it is and
would be counter productive. My vote would be to keep it's development
along its current path (even though I personally favour the micro-kernel
approach if done well).
Best regards,
Nick
--
************************************************************************
+ n...@xwing.org +
Path: bga.com!news.sprintlink.net!howland.reston.ans.net!swrinde!sgiblab!
sgigate.sgi.com!fido.asd.sgi.com!fubar!lm
From: lm@fubar (Larry McVoy)
Newsgroups: comp.os.linux.development
Subject: Re: Linux 2 - The Microkernel
Date: 5 Dec 1994 20:39:39 GMT
Organization: Silicon Graphics Inc., Mountain View, CA
Lines: 35
Message-ID: <3bvtqb$n9l@fido.asd.sgi.com>
References: <1994Nov30.110346.5280@bay.cc.kcl.ac.uk> <M2WUBVWI@math.fu-berlin.de>
<JRICHARD.94Dec2180352@sable.uml.edu> <1994Dec5.051622.6997@xwing.xwing.org>
Reply-To: l...@slovax.engr.sgi.com
NNTP-Posting-Host: fubar.engr.sgi.com
X-Newsreader: TIN [version 1.2 PL1]
: Getting back to the question of whether Linux should be re-written
: as a micro-kernel? No way! It works great just the way it is and
: would be counter productive. My vote would be to keep it's development
: along its current path (even though I personally favour the micro-kernel
: approach if done well).
I can vouch for a lot of what this gentleman is saying: QNX is a good, fast,
microkernel. It's the only one that I know of that really lives up to
the promise of the microkernel architecture. The others are all fat and
slow. Why is that? Two reasons:
1) The x86 architecture does not have a lot of state - it is
possibe to do context switches quite quickly. The reason is
that there are not a lot of registers to save and restore.
This is usually not relevant because most OS's are so fat that
the difference between 8 and 32 registers is lost in the noise;
that's not the case for QNX.
2) Well designed and well written code. I can't emphasize
enough the discipline that it takes to write something as good
as QNX. With absolutely no offense meant, Linux is not in the
same league. Neither is Mach, Solaris, or any of the other
Unix systems. You simply can't afford to add *any* extra
instructions in critical paths if you want to have speed. That
takes a lot of discipline because people will add bloat one
instruction at a time, measuring each step and proudly
proclaiming "my new feature that marketing wanted only adds 2%
overhead". Those overheads add up. We context switch in
10s of usecs, with each usec roughly the cost of a cache miss.
There isn't any room to spare.
Conclusion: I agree with the author above: leave Linux in the current form.
--
---
Larry McVoy (415) 390-1804 l...@sgi.com
Path: bga.com!news.sprintlink.net!howland.reston.ans.net!gatech!
news-feed-1.peachnet.edu!gallifrey!newcombe
From: newco...@aa.csc.peachnet.edu (Dan Newcombe)
Newsgroups: comp.os.linux.development
Subject: Re: Linux 2 - The Microkernel
Date: Mon, 5 Dec 1994 16:42:16 UNDEFINED
Organization: Clayton State College
Lines: 24
Message-ID: <newcombe.1064.011D4FBC@aa.csc.peachnet.edu>
References: <COLLINS.94Nov30150011@zeke.paros.com>
<3bipc6$dl2@uk-usenet.uk.sun.com> <3bovjc$18t@drax.isi.edu>
NNTP-Posting-Host: 131.144.82.16
X-Newsreader: Trumpet for Windows [Version 1.0 Rev B]
In article <3bovjc$...@drax.isi.edu> rog...@drax.isi.edu (Craig Milo Rogers)
writes:
> Now, consider that Linux already supports (to varying degrees)
>its native interpretation of POSIX, iBCS2, DOSEMU, and WINE, it is
>apparent that Linux supports multiple personalities, another
>characteristic of microkernels according to the sales literature.
>Dynamically-loaded kernel modules are available. Kernel threads might
>me coming.
(I still don't see the difference between starting a thread and starting
another process. Can someone help my ignorance here :)
Anyway, DOSEMU and Wine are not personalities. They are emulators. By your
analogy, DOS also supports multiple personalities (dos, windoze, and with
emulators: c/pm, apple, c64, zx81. And if you believe myth's: sega genesis
and amigas :)
And I thought that POSIX was just a standard that Linux conformed to.
-Dan
--
Dan Newcombe newco...@aa.csc.peachnet.edu
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"And the man in the mirror has sad eyes." -Marillion
Path: bga.com!news.sprintlink.net!howland.reston.ans.net!swrinde!sgiblab!
sgigate.sgi.com!fido.asd.sgi.com!slovax!lm
From: l...@slovax.engr.sgi.com (Larry McVoy)
Newsgroups: comp.os.linux.development
Subject: Re: Linux 2 - The Microkernel
Date: 6 Dec 1994 07:08:38 GMT
Organization: Silicon Graphics Inc., Mountain View, CA
Lines: 42
Message-ID: <3c12lm$qbp@fido.asd.sgi.com>
References: <COLLINS.94Nov30150011@zeke.paros.com>
<3bipc6$dl2@uk-usenet.uk.sun.com> <3bovjc$18t@drax.isi.edu>
<newcombe.1064.011D4FBC@aa.csc.peachnet.edu>
Reply-To: l...@slovax.engr.sgi.com
NNTP-Posting-Host: slovax.engr.sgi.com
X-Newsreader: TIN [version 1.2 PL2]
Dan Newcombe (newco...@aa.csc.peachnet.edu) wrote:
: In article <3bovjc$...@drax.isi.edu> rog...@drax.isi.edu (Craig Milo Rogers)
writes:
: > Now, consider that Linux already supports (to varying degrees)
: >its native interpretation of POSIX, iBCS2, DOSEMU, and WINE, it is
: >apparent that Linux supports multiple personalities, another
: >characteristic of microkernels according to the sales literature.
: >Dynamically-loaded kernel modules are available. Kernel threads might
: >me coming.
: (I still don't see the difference between starting a thread and starting
: another process. Can someone help my ignorance here :)
A thread runs in the same address space as the other threads. A new
process typically does not.
Plan 9 does not distinguish between threads and processes. Plan 9's
version of fork(), I believe it is called rfork() (a misnomer if ever I
saw one) takes arguments to specify whcih things you want shared
between parent and child. There are a set of arguments that give you
standard Unix fork() semantics. You can say that you want to share the
address space, the file descriptors, mappings, etc. Or not. It's up
to you.
But all "threads" are full blown processes, with kernel state. There
is no need to program one way if you are a user level thread and
another if you are a kernel level thread. (That is the Sun model, a
model that I consider to be a gross botch. And I used to work there.)
Rob Pike's famous, and in my opinin, correct, statement is ``If you
think you need threads then your processes are too fat.'' It's a
good statement, a true statement.
: And I thought that POSIX was just a standard that Linux conformed to.
POSIX comes in several flavors or layers. There is POSIX standard
P1003.1 which is the system call/library interface. There is
P1003.2 which is the shell and shell level utilities (I think it
includes vi). Etc. Linux is sort of 1003.1 compliant. An interesting
question: has anyone run a test suite against it?
--
---
Larry McVoy (415) 390-1804 l...@sgi.com
Path: bga.com!news.sprintlink.net!howland.reston.ans.net!agate!chaffee
From: chaf...@bugs-bunny.cs.berkeley.edu (Gordon Chaffee)
Newsgroups: comp.os.linux.development
Subject: Re: Linux 2 - The Microkernel
Date: 6 Dec 1994 07:24:32 GMT
Organization: University of California, Berkeley
Lines: 16
Message-ID: <3c13jg$cdb@agate.berkeley.edu>
References: <COLLINS.94Nov30150011@zeke.paros.com> <3bovjc$18t@drax.isi.edu>
<newcombe.1064.011D4FBC@aa.csc.peachnet.edu> <3c12lm$qbp@fido.asd.sgi.com>
NNTP-Posting-Host: bugs-bunny.cs.berkeley.edu
In article <3c12lm$...@fido.asd.sgi.com>,
Larry McVoy <l...@slovax.engr.sgi.com> wrote:
>Rob Pike's famous, and in my opinin, correct, statement is ``If you
>think you need threads then your processes are too fat.'' It's a
>good statement, a true statement.
Threads have at least one useful purpose: in multiprocessor systems,
they help the system make better use of the processing power available.
This isn't true under Linux right now since it doesn't support
multiprocessor systems, but there are valid reasons to use threads.
Gordon Chaffee
chaf...@bugs-bunny.cs.berkeley.edu
Path: bga.com!news.sprintlink.net!howland.reston.ans.net!gatech!
newsfeed.pitt.edu!ddj
From: d...@pitt.edu (Doug Dejulio)
Newsgroups: comp.os.linux.development
Subject: Re: Linux 2 - The Microkernel
Date: 7 Dec 1994 04:28:56 GMT
Organization: University of Pittsburgh
Lines: 33
Message-ID: <3c3dm8$gst@usenet.srv.cis.pitt.edu>
References: <COLLINS.94Nov30150011@zeke.paros.com>
<newcombe.1064.011D4FBC@aa.csc.peachnet.edu> <3c12lm$qbp@fido.asd.sgi.com>
<3c13jg$cdb@agate.berkeley.edu>
NNTP-Posting-Host: unixs3.cis.pitt.edu
In article <3c13jg$...@agate.berkeley.edu>,
Gordon Chaffee <chaf...@bugs-bunny.cs.berkeley.edu> wrote:
>In article <3c12lm$...@fido.asd.sgi.com>,
>Larry McVoy <l...@slovax.engr.sgi.com> wrote:
>>Rob Pike's famous, and in my opinin, correct, statement is ``If you
>>think you need threads then your processes are too fat.'' It's a
>>good statement, a true statement.
>
>Threads have at least one useful purpose: in multiprocessor systems,
>they help the system make better use of the processing power available.
>This isn't true under Linux right now since it doesn't support
>multiprocessor systems, but there are valid reasons to use threads.
Let's re-state the original claim in slightly different language:
If you think you need threads, then you need to take the application
for which you think threads are neccesary and split it into several
separate processes, which communicate via shared memory and
networking.
This lets you take advantage of multiprocessor systems just as well as
threads do. It *also* lets you take advantage of splitting your job
up among entirely separate computers, even if they're not binary
compatible. Mathematica (with separate notebook + kernel) is an
example of this (though both parts are still hugely bloated).
--
Doug DeJulio
mailto:d...@pitt.edu
http://www.pitt.edu/~ddj/
Newsgroups: comp.os.linux.development
Path: bga.com!news.sprintlink.net!howland.reston.ans.net!swrinde!pipex!
sunsite.doc.ic.ac.uk!uknet!info!iialan
From: iia...@iifeak.swan.ac.uk (Alan Cox)
Subject: Re: Linux 2 - The Microkernel
Message-ID: <D0GKEy.DKy@info.swan.ac.uk>
Sender: n...@info.swan.ac.uk
Nntp-Posting-Host: iifeak.swan.ac.uk
Organization: Institute For Industrial Information Technology
References: <1994Nov30.110346.5280@bay.cc.kcl.ac.uk>
<3bibr0$jqv@csnews.cs.colorado.edu> <3bu4g8$qsv@pdq.coe.montana.edu>
Date: Wed, 7 Dec 1994 20:47:22 GMT
Lines: 105
In article <3bu4g8$...@pdq.coe.montana.edu> n...@bsd.coe.montana.edu
(Nate Williams) writes:
>become commonplace on the desktop IMHO. It is *MUCH* more difficult to
>implement SMP with macro vs. microkernels.
What proof do you offer for that assertion, given that almost every real
multiprocessor OS in existance is not microkernel. TOPS-10 wasn't
microkernel I can assure you.
>I think this is no longer the case. In most places where Linux and
>micro-kernels are developed, it is understood that micro-kernel means
>micro-functionality, where most of the processing is NOT done in the
>kernel but in separate processes.
You put things in the kernel for speed, in user space for size and ease of
use. It makes no odds how you label your kernel, the decisions are the same.
The performance issues are the same.
>3. It's easier to develop and research new file system types, since you
> can debug them as a user process. This goes for other OS research as
I can anyway. Linux has user mode file systems, loadable file systems,
loadable networking stacks. It doesn't have a loadable scheduler but
then changing scheduler on the fly will be fun...
>4. Micro-kernels *force* a layer of abstraction on the programmer which cause
> them to write more maintainable code. Bad programmers will always
I have a compiler and training for that. Neither of them screw up
performance like a forced message passing system.
>5. There is a standard API that allows for ease of understanding in a
> micro-kernel. A monolithic kernel becomes too large for one person
> to understand completely (though I'm sure Linus is doing a pretty
> fair job of it.)
This is an old argument and many times proved bogus. A well structured
kernel is no different be it microkernel or macrokernel. If its well
designed you don't need to know how other bits work.
>6. The kernel can be 'scaled' for embedded applications easier. For
> many applications, there is no need for a FS or networking. This
> can be accomplished via loadable kernel modules somewhat in a
> monolithic kernel, but it doesn't works as well.
Why not. What is the difference between a loadable module or a microkernel
loaded module - apart from the microkernel message pass is slower.
>7. Micro-kernels seem to make it easier to do Real-Time support. (Most
> of the real-time stuff I've seen is implemented on micro-kernels.)
OS/9 isn't a microkernel, its a full monolithic kernel, just a very small
one, ditto everything else I've seen barring maybe QNX, and I've not dug
into QNX enough to see if it merely function calls or message passes.
>Why was Linux written in the first place? There already existed plenty
>of unixes for the x86, so plenty of man years of effort have been
>exerted already. ;)
>It was done Linus wanted to. Why discourage folks from attempting to do
>it. This is just plain silly. The above advantages are enough to
>justify writing just for the fun of it.
Because there were no credible free ones at the time. Nobody I hope is
saying don't do it, just "we dont see the point".
>> 2. The loss of the multi-threaded nature inherent in a macro kernel
>Actually, with SMP and Real-Time stuff using micro-kernels, I don't see
>where you get this from. Please expound.
Most microkernels end up with servers. Message based servers are either
threaded again or process one message at a time. Look at say the minix
fs code for a classic example of this - or the older amiga fs stuff.
>Since context switches happen faster (if properly designed) in a
>micro-kernel my assertion is that the overall context in a micro-kernel
>is no worse and possibly better than a standard macro-kernel. The
>advantage is that it's easier to write better code in a micro-kernel.
Context switches happen faster.. well unless your cpu executes the same
instruction at different speeds according to the label on your software I
fail to see how you can explain that. Especially on a 386/486 where if you want
to switch memory protection rules between contexts you take a page table
cache hit.
>be seen in the future, and not directly. If speed were the only issue
>you'd still be running 0.96, but people want more features and more
>stuff. Also, with the resources of the Linux folks working on a
1.1.72 is a lot faster than 0.97.5. I dont have 0.96 to benchmark
>Finally, given the popularity of Linux, I suspect that if Linux moved
>toward a micro-kernel design hardware support (if you mean device
>drivers) would be quick to follow. And there is the immediate benefit
>of multi-platform support that Mach would buy you. Mach runs on a lot
>more platforms than Linux does today.
Mach isnt a microkernel, mach is a classic example of the 'not a
microkernel' but claims to be genre - its HUGE. Anyway Linux is getting
portable now as people shift it to PPC, ARM, ALPHA, 680x0 architectures.
Alan
--
..-----------,,----------------------------,,----------------------------,,
// Alan Cox // iia...@www.linux.org.uk // GW4PTS@GB7SWN.#45.GBR.EU //
``----------'`--[Anti Kibozing Signature]-'`----------------------------''
One two three: Kibo, Lawyer, Refugee :: Green card, Compaq come read me...
Path: bga.com!news.sprintlink.net!howland.reston.ans.net!math.ohio-state.edu!
caen!usenet.coe.montana.edu!bsd.coe.montana.edu!nate
From: n...@bsd.coe.montana.edu (Nate Williams)
Newsgroups: comp.os.linux.development
Subject: Re: Linux 2 - The Microkernel
Date: 8 Dec 1994 01:09:55 GMT
Organization: Montana State University, Bozeman Montana
Lines: 83
Message-ID: <3c5md3$t3g@pdq.coe.montana.edu>
References: <1994Nov30.110346.5280@bay.cc.kcl.ac.uk>
<3bibr0$jqv@csnews.cs.colorado.edu> <3bu4g8$qsv@pdq.coe.montana.edu>
<D0GKEy.DKy@info.swan.ac.uk>
NNTP-Posting-Host: bsd.coe.montana.edu
In article <D0GKEy....@info.swan.ac.uk>,
Alan Cox <iia...@iifeak.swan.ac.uk> wrote:
>You put things in the kernel for speed, in user space for size and ease of
>use.
No you put things in the kernel because there is no place else to put
them. If you can provide ways of doing things in non-privileged and/or
privileged servers which are easier to develop and understand, then put
them there. There are fast MK implementations out there which are as
fast or faster than almost all of the free IK's who do most of the
work outside of the 'kernel'.
>It makes no odds how you label your kernel, the decisions are the same.
>The performance issues are the same.
>
>>3. It's easier to develop and research new file system types, since you
>> can debug them as a user process. This goes for other OS research as
>
>I can anyway. Linux has user mode file systems, loadable file systems,
>loadable networking stacks. It doesn't have a loadable scheduler but
>then changing scheduler on the fly will be fun...
It's still in the kernel, and if you hose up the FS you've completely
hosed up the kernel as well. If you screw up a server stack, then
you've got a dead FS server (which is running separately from the normal
server). If you screw up the kernel stack you've got a core dump.
Also, let's see you single step through a kernel as easily as you can
through a server process.
>>4. Micro-kernels *force* a layer of abstraction on the programmer which cause
>> them to write more maintainable code. Bad programmers will always
>
>I have a compiler and training for that. Neither of them screw up
>performance like a forced message passing system.
You *don't* have to take a performance hit. And, I'll you write all of
your code in assembly since you're trained for that. Recent studies
have shown that 90% of the money spent on development is in maintenance.
The easier the code is to understand the better, and just because YOU
are a great programmer doesn't mean the next person is going to be as
talented as you are.
>>5. There is a standard API that allows for ease of understanding in a
>> micro-kernel. A monolithic kernel becomes too large for one person
>> to understand completely (though I'm sure Linus is doing a pretty
>> fair job of it.)
>
>This is an old argument and many times proved bogus. A well structured
>kernel is no different be it microkernel or macrokernel. If its well
>designed you don't need to know how other bits work.
Show me *one* well structured IK. Linux is understandable, but for the
average user they can't understand the complexity of the entire thing.
Joe average programmers relies on the talents of Linus and the others
to handle the 'big picture'. This doesn't have to be the case.
>>6. The kernel can be 'scaled' for embedded applications easier. For
>> many applications, there is no need for a FS or networking. This
>> can be accomplished via loadable kernel modules somewhat in a
>> monolithic kernel, but it doesn't works as well.
>
>Why not. What is the difference between a loadable module or a microkernel
>loaded module - apart from the microkernel message pass is slower.
Let's see you fit Linux on a 1MB machine and have it perform useful
tasks.
>Mach isnt a microkernel, mach is a classic example of the 'not a
>microkernel' but claims to be genre - its HUGE. Anyway Linux is getting
>portable now as people shift it to PPC, ARM, ALPHA, 680x0 architectures.
Read the literature. 'Micro-kernel' has never meant small in size. It
means small in functionality. And, this 'portability' issue is espoused
by you but recent articles by the porters paint a much different
picture.
Nate
--
n...@bsd.coe.montana.edu | FreeBSD dude and all around tech.
n...@cs.montana.edu | weenie.
work #: (406) 994-5980 | Unemployed, looking for permanant work in
home #: (406) 586-0579 | CS/EE field.
Path: bga.com!news.sprintlink.net!howland.reston.ans.net!gatech!
bloom-beacon.mit.edu!senator-bedfellow.mit.edu!maze.MIT.EDU!ghudson
From: ghud...@mit.edu (Greg Hudson)
Newsgroups: comp.os.linux.development
Subject: Re: Linux 2 - The Microkernel
Date: 8 Dec 1994 04:49:47 GMT
Organization: Massachvsetts Institvte of Technology
Lines: 49
Message-ID: <3c639b$f51@senator-bedfellow.MIT.EDU>
References: <1994Nov30.110346.5280@bay.cc.kcl.ac.uk>
<3bibr0$jqv@csnews.cs.colorado.edu> <3bu4g8$qsv@pdq.coe.montana.edu>
<D0GKEy.DKy@info.swan.ac.uk> <3c5md3$t3g@pdq.coe.montana.edu>
NNTP-Posting-Host: maze.mit.edu
X-Newsreader: TIN [version 1.2 PL2]
Nate Williams (n...@bsd.coe.montana.edu) wrote:
: In article <D0GKEy....@info.swan.ac.uk>,
: Alan Cox <iia...@iifeak.swan.ac.uk> wrote:
: >You put things in the kernel for speed, in user space for size and ease of
: >use.
: No you put things in the kernel because there is no place else to put
: them. If you can provide ways of doing things in non-privileged and/or
: privileged servers which are easier to develop and understand, then put
: them there. There are fast MK implementations out there which are as
: fast or faster than almost all of the free IK's who do most of the
: work outside of the 'kernel'.
The only example I've seen mentioned is QNX, and last I checked, QNX
isn't doing the same work as Unix. (For instance, I don't think the
page table actually changes during a context switch.) I don't see
why microkernel advocates try to fool themselves by saying that you
don't pay a performance penalty for having a microkernel; it's a very
simple thought experiment to try replacing all message passes with
function calls within a single address space.
: >I can anyway. Linux has user mode file systems, loadable file systems,
: >loadable networking stacks. It doesn't have a loadable scheduler but
: >then changing scheduler on the fly will be fun...
: It's still in the kernel, and if you hose up the FS you've completely
: hosed up the kernel as well. If you screw up a server stack, then
: you've got a dead FS server (which is running separately from the normal
: server). If you screw up the kernel stack you've got a core dump.
: Also, let's see you single step through a kernel as easily as you can
: through a server process.
Check out userfs sometime; it allows you to run the file system in a
user process. This isn't actually anything new; you can also implement
a file system as a local NFS server. Matthew Blaze (from Bell Labs)
developed a portable implementation of an encrypted file system using
a local NFS server just recently.
Outside of the embedded applications market, I don't think microkernels
provide any significant functionality which can't be incorporated into
an integrated kernel, and people who claim otherwise are probably trying
to market a (rather boring) software engineering strategy as something
more. It may be worth the performance penalty to use a microkernel
strategy for implementing an operation system (if, for example, it really
does free up enough maintenance cost to allow development of
optimizations), but I personally feel that it's a mistake to use the
hardware at runtime to enforce divisions which could be enforced by the
language at compile time.
Newsgroups: comp.os.linux.development
Path: bga.com!news.sprintlink.net!howland.reston.ans.net!vixen.cso.uiuc.edu!
uwm.edu!biosci!parc!rocksanne!news
From: bb...@roch803.mc.xerox.com (Bruce Bigby)
Subject: Re: Linux 2 - The Microkernel
Message-ID: <1994Dec7.155121.16454@news.wrc.xerox.com>
Sender: n...@news.wrc.xerox.com
Reply-To: brucebi...@aol.com
Organization: Xerox Corporation, Webster NY
References: <3bvtqb$n9l@fido.asd.sgi.com>
Date: Wed, 7 Dec 1994 15:51:21 GMT
Lines: 55
In article n...@fido.asd.sgi.com, lm@fubar (Larry McVoy) writes:
>: Getting back to the question of whether Linux should be re-written
>: as a micro-kernel? No way! It works great just the way it is and
>: would be counter productive. My vote would be to keep it's development
>: along its current path (even though I personally favour the micro-kernel
>: approach if done well).
>
>I can vouch for a lot of what this gentleman is saying: QNX is a good, fast,
>microkernel. It's the only one that I know of that really lives up to
>the promise of the microkernel architecture. The others are all fat and
>slow. Why is that? Two reasons:
>
> 1) The x86 architecture does not have a lot of state - it is
> possibe to do context switches quite quickly. The reason is
> that there are not a lot of registers to save and restore.
> This is usually not relevant because most OS's are so fat that
> the difference between 8 and 32 registers is lost in the noise;
> that's not the case for QNX.
>
> 2) Well designed and well written code. I can't emphasize
> enough the discipline that it takes to write something as good
> as QNX. With absolutely no offense meant, Linux is not in the
> same league. Neither is Mach, Solaris, or any of the other
> Unix systems. You simply can't afford to add *any* extra
> instructions in critical paths if you want to have speed. That
> takes a lot of discipline because people will add bloat one
> instruction at a time, measuring each step and proudly
> proclaiming "my new feature that marketing wanted only adds 2%
> overhead". Those overheads add up. We context switch in
> 10s of usecs, with each usec roughly the cost of a cache miss.
> There isn't any room to spare.
>
>Conclusion: I agree with the author above: leave Linux in the current form.
>--
>---
>Larry McVoy (415) 390-1804 l...@sgi.com
I disgree. I think that someone should write a true lean ukernel Linux. Of
course, the current Linux and that ukernel Linux will most undoubtedly, be
incompatible. QNX, at one time was affordable to those who wanted to indulge,
but since the introduction of QNX4 it's became very expensive. I believe the
base OS with all of the feature that a comparable Linux system has costs
about $1000.00! This was not always the case. But when you're as good as QNX
and, basically, the only game in town, you can command a premium price! This
leaves all of the simply curious types out in the cold. I can't afford to
fork over $1000.00 just to have the priviledge of.... For this reason alone,
we should have a true uKernel, based on QNX concepts. I say go for it!
By the way, I have QNX 3.X, or was it QNX 2.x? I forget...have to look at
the disks when I get home.
Bruce
Path: bga.com!news.sprintlink.net!howland.reston.ans.net!gatech!
newsfeed.pitt.edu!ctc.com!news.mic.ucla.edu!library.ucla.edu!galaxy.ucr.edu!
corsa!cvarner
From: cvar...@corsa.ucr.edu (Curtis Varner)
Newsgroups: comp.os.linux.development
Subject: Re: Linux 2 - The Microkernel
Date: 8 Dec 1994 05:25:24 GMT
Organization: UC Riverside, Dept. of Computer Science
Lines: 58
Message-ID: <3c65c4$ov7@galaxy.ucr.edu>
References: <COLLINS.94Nov30150011@zeke.paros.com> <3c12lm$qbp@fido.asd.sgi.com>
<3c13jg$cdb@agate.berkeley.edu> <3c3dm8$gst@usenet.srv.cis.pitt.edu>
NNTP-Posting-Host: cs.ucr.edu
In article <3c3dm8$...@usenet.srv.cis.pitt.edu>,
Doug Dejulio <d...@pitt.edu> wrote:
>In article <3c13jg$...@agate.berkeley.edu>,
>Gordon Chaffee <chaf...@bugs-bunny.cs.berkeley.edu> wrote:
>>In article <3c12lm$...@fido.asd.sgi.com>,
>>Larry McVoy <l...@slovax.engr.sgi.com> wrote:
>>>Rob Pike's famous, and in my opinin, correct, statement is ``If you
>>>think you need threads then your processes are too fat.'' It's a
>>>good statement, a true statement.
>>
>>Threads have at least one useful purpose: in multiprocessor systems,
>>they help the system make better use of the processing power available.
>>This isn't true under Linux right now since it doesn't support
>>multiprocessor systems, but there are valid reasons to use threads.
>
>Let's re-state the original claim in slightly different language:
>
> If you think you need threads, then you need to take the application
> for which you think threads are neccesary and split it into several
> separate processes, which communicate via shared memory and
> networking.
>
>This lets you take advantage of multiprocessor systems just as well as
>threads do. It *also* lets you take advantage of splitting your job
>up among entirely separate computers, even if they're not binary
>compatible. Mathematica (with separate notebook + kernel) is an
>example of this (though both parts are still hugely bloated).
>
I disagree that using shared memory and forking is as
effective or as easy as using threads. I have written multi-threaded
client-server apps, as well as shared memory apps, and yes, I have
even written distributed shared memory apps (on AIX systems no less,
ughh). As for code complexity, the overhead of adding all those cool
shmget, shmat calls, etc. is probably about equivalent to the
thread_create, etc. calls. However, when using threads, you have a
lot of other tools, to help write the concurrency control code, such
as mutual exclusion locks, etc. Every shared memory app I wrote took
a lot longer to write and debug, as I had to write the code to do the
locking, unlocking, of shared resources.
Also, unless you do all the forks initially (such as in many
implementations of nfsd), you pay a big hit in performance, as forks
are more expensive than creating a thread. Now that I think about it,
a multithreaded program would use less memory/system resources than
multiple children would. I would say that the fork/exec memory style
is okay if you don't have access to threads - but use the threads if
you got them.
As for distributed applications, well, you don't really have
much choice, do you. Unless you want to use message passing (which I
kinda lean away from).
--
Curtis Varner
cvar...@cs.ucr.edu
University of CA, Riverside
Path: bga.com!news.sprintlink.net!hookup!newshost.marcam.com!news.mathworks.com!
udel!gatech!howland.reston.ans.net!usc!news.isi.edu!not-for-mail
From: rog...@drax.isi.edu (Craig Milo Rogers)
Newsgroups: comp.os.linux.development
Subject: Re: Linux 2 - The Microkernel
Date: 7 Dec 1994 22:26:40 -0800
Organization: USC Information Sciences Institute
Lines: 74
Message-ID: <3c68v0$ha4@drax.isi.edu>
References: <COLLINS.94Nov30150011@zeke.paros.com>
<3bipc6$dl2@uk-usenet.uk.sun.com> <3bovjc$18t@drax.isi.edu>
<newcombe.1064.011D4FBC@aa.csc.peachnet.edu>
NNTP-Posting-Host: drax.isi.edu
In article <newcombe.1064.011D4...@aa.csc.peachnet.edu>
newco...@aa.csc.peachnet.edu (Dan Newcombe) writes:
>In article <3bovjc$...@drax.isi.edu> rog...@drax.isi.edu
(Craig Milo Rogers) writes:
>> Now, consider that Linux already supports (to varying degrees)
>>its native interpretation of POSIX, iBCS2, DOSEMU, and WINE, it is
>>apparent that Linux supports multiple personalities, another
>>characteristic of microkernels according to the sales literature.
>>Dynamically-loaded kernel modules are available. Kernel threads might
>>me coming.
>
>(I still don't see the difference between starting a thread and starting
>another process. Can someone help my ignorance here :)
The terms are generally differentiated by the baggage they
carry with them. In the Unix world, a creating a process generally means
creating a new user data apace (initialized from the parent), creating a
new stack space (initialized from the parent), creating a new file
descriptor space (initialized form the parent), creating a new signal
space (initialized from the parent, mainly), etc. Each process is a
focus of processor activity, but there's a lot of other state that
goes with it.
A thread, or light-weight process, is simply a program
counter (and a set of processor registers -- but not necessarily
all of them). Creating a new thread does not create a new user
data space. It might create a new stack space. It would not create
a new file descriptor space. Signals are an interesting problem.
There are certain things that are more convenient to do with
multiple threads than with multiple classic processes. For example,
threads just naturally share data space; with processes you have to
explicitly map shared memory and allocate your shared data scructures
there. This is handy when performing complex I/O interactions where
Unix' original communicating sequential process model is clumbsy.
Threads may also provide useful approaches to high-performance
I/O, although I personally favor TOP-10's shared ring buffer approach.
I suppose onbe can discuss whether TOPS-10's software interrupts and
OS/360's POSTs should be considered thread mechanisms.
>Anyway, DOSEMU and Wine are not personalities. They are emulators. By your
>analogy, DOS also supports multiple personalities (dos, windoze, and with
>emulators: c/pm, apple, c64, zx81. And if you believe myth's: sega genesis
>and amigas :)
>
>And I thought that POSIX was just a standard that Linux conformed to.
Linux conforms to POSIX (I'm told; I haven't read an actual
POSIX standard in many years). As discussed in this newsgroup,
though, POSIX allows implementations some latitude at places. Linux
makes one set of choices, thus creating an interpretation of the POSIX
spec; other POSIX implementations may take different choices, creating
other interpretations.
It is true that "personality" has a technical meaning in the
context of the Linux kernel, with two choices: native, and iBCS2. I
was not thinking of that definition of the term. Rather, I'll
distinguish (for the purpose of debate) between "emulator" and
"personality" on a very soft basis: how "integrated" are the services
being provided into the general environment perceived by the user or
programmer (as appropriate)?
In a classic emulator, once you enter emulated mode, it is
difficult to access services of the parent mode, including parent file
systems. A system with multiple personalities has tighter coupling
between the resoures used in the different modes. The current Windows
must have at least three personalities: 16-bit, 32-bit, and DOS-box.
The CP/M, etc. emulators aren't integrated.
I agree that DOSEMU and WINE aren't as tightly coupled into
Linux as iBCS is. With loadable kernel modules, perhaps they'll
become more tightly coupled?
Craig Milo Rogers
Path: bga.com!news.sprintlink.net!howland.reston.ans.net!gatech!swrinde!
sgiblab!sgigate.sgi.com!fido.asd.sgi.com!fubar!lm
From: lm@fubar (Larry McVoy)
Newsgroups: comp.os.linux.development
Subject: Re: Linux 2 - The Microkernel
Date: 8 Dec 1994 22:13:31 GMT
Organization: Silicon Graphics Inc., Mountain View, CA
Lines: 42
Message-ID: <3c80eb$h1o@fido.asd.sgi.com>
References: <3bvtqb$n9l@fido.asd.sgi.com>
<1994Dec7.155121.16454@news.wrc.xerox.com>
Reply-To: l...@slovax.engr.sgi.com
NNTP-Posting-Host: fubar.engr.sgi.com
X-Newsreader: TIN [version 1.2 PL1]
Bruce Bigby (bb...@roch803.mc.xerox.com) wrote:
: I disgree. I think that someone should write a true lean ukernel Linux. Of
What's your experience in writing operating systems? Have you ever
a) written swtch() - the code that implements a context switch?
b) written a device driver?
c) written a file system?
d) understood a reasonable VM system?
If you are one of the few that can say yes to all/some of the above, then
maybe I (and others) should listen to you. If you have all that experience,
I find it difficult to believe you would be a big uKernel fan. If you
browse through the postings recently on this thread, I think you'll see
the experienced people saying "no ukernel" and the newer folks saying
"uKernel, yeah, cool".
I've been doing OS work for about 10 years, all Unix, from 10 million
dollar (or was it 30?) supers down to 3K PCs. One of the things I
learned was to listen carefully to those with more experience.
I've also developed a "difficulty meter". Doing a good microkernel is
really hard. I was at Sun during Spring development. I'm not
particular impressed with Spring, it's fine as uKernels go, but I am
most certainly impressed with the talent that is being applied to the
Spring development. They are some impressive people, experienced,
focussed, funded, and trying to build what you are proposing. They
haven't succeeded yet. So putting very talented people to work on a
hard problem does not guarentee a solution.
It's a hard problem. Converting Linux to a uKernel would almost
certainly make it useless. It's not that it could not be done, it is
that doing it is a Hard Problem, far bigger than you realize.
I personally support the approach hinted at by someone (name?) from Indiana:
[s]he said to move Linux forward by making as much as possible dynamically
loaded at boot time (or later). The base kernel itself need not be large.
That's a pretty good compromise between a big pile of Doo Doo and a tiny
(ha) pile of elegant ukernel.
--
---
Larry McVoy (415) 390-1804 l...@sgi.com
Newsgroups: comp.os.linux.development
Path: bga.com!news.sprintlink.net!hookup!nic.ott.hookup.net!ecicrl!
revcan!quantum!danh
From: d...@qnx.com (Dan Hildebrand)
Subject: Re: Linux 2 - The Microkernel
Message-ID: <#j+##+q#@qnx.com>
Date: Thu, 08 Dec 94 17:15:57 GMT
Organization: QNX Software Systems
References: <1994Nov30.110346.5280@bay.cc.kcl.ac.uk>
<D0GKEy.DKy@info.swan.ac.uk> <3c5md3$t3g@pdq.coe.montana.edu>
<3c639b$f51@senator-bedfellow.MIT.EDU>
Lines: 70
In article <3c639b$...@senator-bedfellow.MIT.EDU>,
Greg Hudson <ghud...@mit.edu> wrote:
>
>The only example I've seen mentioned is QNX, and last I checked, QNX
>isn't doing the same work as Unix. (For instance, I don't think the
>page table actually changes during a context switch.)
Processes under QNX each run in their own virtual address space, fully
memory protected from each other. Yes, there are tricks in how the page
table is managed, but from the perspective of the user-level process the
functionality is the same, and that's what matters. One limitation is that
QNX does not currently implement paging to disk, but that's just an issue
of setting the not-present bits on the pages and doesn't make any
difference to the code path for context switching between two
memory-resident processes. The paging code would only be invoked in the
case where a non-resident page was accessed.
>I don't see
>why microkernel advocates try to fool themselves by saying that you
>don't pay a performance penalty for having a microkernel; it's a very
>simple thought experiment to try replacing all message passes with
>function calls within a single address space.
Once you replace the message passes with function calls, how do you
recreate the concurrency inherent in having multiple processes perform your
OS work, rather than process activations? Don't forget to include the
semaphores, and other stuff that needs to be present to keep things
working. Also, how do you make those function calls operate transparently
across the network, to duplicate the case where the pair of communicating
processes weren't on the same node?
The whole point of a microkernel is to simplify the kernel path, and in the
process make it as lean and fast as possible. Having acheived this, the
challenge then is to be to add the functionality back on with optional
processes without losing the performance gain of the microkernel in the
first place. Having achieved this, the functionality gains allow you to
structure your applications and systems to take advantage of this, and
achieve further system-level performance gains.
>Outside of the embedded applications market, I don't think microkernels
>provide any significant functionality which can't be incorporated into
>an integrated kernel, and people who claim otherwise are probably trying
>to market a (rather boring) software engineering strategy as something
>more.
In a microkernel OS where all services are accessed via message passing
between processes, it becomes possible for the message passing through the
microkernel to be redirected to microkernels on other nodes connected on a
network. The end result is that the microkernels merge to become a single,
logical kernel, with all the resources of all the nodes accessible to all
processes on the network. This level of network transparency isn't
attainable with conventional TCP/IP services at all. How's that for a
functionality improvement? :-)
The papers at ftp.qnx.com:/pub/papers describe a lot of this.
>It may be worth the performance penalty to use a microkernel
>strategy for implementing an operation system (if, for example, it really
>does free up enough maintenance cost to allow development of
>optimizations), but I personally feel that it's a mistake to use the
>hardware at runtime to enforce divisions which could be enforced by the
>language at compile time.
I doubt you can correct all potential programming errors at compile time.
For a mission critical application, being able to intelligently recover
from runtime coding errors is a valuable capability.
--
Dan Hildebrand d...@qnx.com QNX Software Systems, Ltd.
phone: (613) 591-0931 x204 (voice) 175 Terence Matthews
(613) 591-3579 (fax) Kanata, Ontario, Canada K2M 1W8
Path: bga.com!news.sprintlink.net!howland.reston.ans.net!swrinde!sgiblab!
sgigate.sgi.com!fido.asd.sgi.com!fubar!lm
From: lm@fubar (Larry McVoy)
Newsgroups: comp.os.linux.development
Subject: Re: Linux 2 - The Microkernel
Date: 9 Dec 1994 01:24:50 GMT
Organization: Silicon Graphics Inc., Mountain View, CA
Lines: 52
Message-ID: <3c8bl2$4mo@fido.asd.sgi.com>
References: <COLLINS.94Nov30150011@zeke.paros.com>
<3bipc6$dl2@uk-usenet.uk.sun.com> <3bovjc$18t@drax.isi.edu>
<newcombe.1064.011D4FBC@aa.csc.peachnet.edu> <3c68v0$ha4@drax.isi.edu>
Reply-To: l...@slovax.engr.sgi.com
NNTP-Posting-Host: fubar.engr.sgi.com
X-Newsreader: TIN [version 1.2 PL1]
Craig Milo Rogers (rog...@drax.isi.edu) wrote:
: The terms are generally differentiated by the baggage they
: carry with them. In the Unix world, a creating a process generally means
: creating a new user data apace (initialized from the parent), creating a
: new stack space (initialized from the parent), creating a new file
: descriptor space (initialized form the parent), creating a new signal
: space (initialized from the parent, mainly), etc. Each process is a
: focus of processor activity, but there's a lot of other state that
: goes with it.
: A thread, or light-weight process, is simply a program
: counter (and a set of processor registers -- but not necessarily
: all of them). Creating a new thread does not create a new user
: data space. It might create a new stack space. It would not create
: a new file descriptor space. Signals are an interesting problem.
Ahem. There are two kinds of threads - those that have kernel context
and those that do not. Everyone should understand by now that user
level threads /wo kernel context are very fast but basically useless.
Yes, you can whip out all your esoteric arguments about the wonderful
things you have done with user level threads, and how select() solves
all your problems (what about signals, hmm?), and I'll tell you "been
there, done that, so have dozens of other people, if they are so useful
how come nobody uses them?).
Threads with kernel level context are basically processes in a shared
address space. They are somewhat slower but much more useful. You can
program in that model. Signals work, file descriptors work, etc, etc.
: There are certain things that are more convenient to do with
: multiple threads than with multiple classic processes. For example,
: threads just naturally share data space; with processes you have to
: explicitly map shared memory and allocate your shared data scructures
: there.
This is not true in Plan 9 or in IRIX or Sequent's Unix. In all of
those you get another process that shares (part of) your address space
and it's just like threads (except signals work and account works and
ps works and file descriptors work and who knows what else works).
It's like threads but better. It is threads but better.
: Threads may also provide useful approaches to high-performance
: I/O, although I personally favor TOP-10's shared ring buffer approach.
: I suppose onbe can discuss whether TOPS-10's software interrupts and
: OS/360's POSTs should be considered thread mechanisms.
IRIX uses their shared address space processes for a number of high
speed multi threaded apps. In fact, I'll bet that more apps are
threaded the IRIX/process way than the Sun way by a long shot.
--
---
Larry McVoy (415) 390-1804 l...@sgi.com
Path: bga.com!news.sprintlink.net!hookup!swrinde!gatech!
bloom-beacon.mit.edu!senator-bedfellow.mit.edu!maze.MIT.EDU!ghudson
From: ghud...@mit.edu (Greg Hudson)
Newsgroups: comp.os.linux.development
Subject: Re: Linux 2 - The Microkernel
Date: 9 Dec 1994 03:35:42 GMT
Organization: Massachvsetts Institvte of Technology
Lines: 52
Message-ID: <3c8jae$do3@senator-bedfellow.MIT.EDU>
References: <1994Nov30.110346.5280@bay.cc.kcl.ac.uk>
<D0GKEy.DKy@info.swan.ac.uk> <3c5md3$t3g@pdq.coe.montana.edu>
<3c639b$f51@senator-bedfellow.MIT.EDU> <#j+##+q#@qnx.com>
NNTP-Posting-Host: maze.mit.edu
X-Newsreader: TIN [version 1.2 PL2]
(It's interesting that QNX actually is changing the page table during
context switches; I had the impression that the QNX context switch times
commonly tabulated next to other kernels' context switch times were for
something more like thread context switching than for process context
switching. Oh, well, serves me right for not doing my homework.)
Dan Hildebrand (d...@qnx.com) wrote:
: Once you replace the message passes with function calls, how do you
: recreate the concurrency inherent in having multiple processes perform your
: OS work, rather than process activations? Don't forget to include the
: semaphores, and other stuff that needs to be present to keep things
: working. Also, how do you make those function calls operate transparently
: across the network, to duplicate the case where the pair of communicating
: processes weren't on the same node?
I certainly wasn't considering multiple processors and distributed
operating systems while talking about that exercise; I was just
observing that there is a performance penalty associated with dividing
up the kernel in a situation where you would normally put the pieces
together and not worry about multiple processors or distributing the
operating system.
Leaving aside the issue of multiple processors, simply dividing up the
kernel's servers and putting them on different machines in a network is
a rather naive way of trying to achieve a distributed operating system,
unless you're talking about a very small network where you can afford to
rely on all of the machines being up at a given time. Although this may
be a better start than an integrated kernel, there's still an awful lot
of work to do before you have a usable system.
(I'm also not convinced that you really want to divide up the kernel.
Plan 9, an integrated kernel, provides a fair amount of network
transparency without having machine A rely on machine B for very basic
things like device drivers and the process table.)
[I wrote:]
: >personally feel that it's a mistake to use the
: >hardware at runtime to enforce divisions which could be enforced by the
: >language at compile time.
: I doubt you can correct all potential programming errors at compile time.
: For a mission critical application, being able to intelligently recover
: from runtime coding errors is a valuable capability.
Certainly, you can't correct all potential programming errors, but you can
prevent all programming errors of the sort microkernels prevent. With a
sufficiently good optimizing compiler, you could use a safe language which
doesn't allow random scribbling over the stack and data segment, and which
signalled exceptions in the case of run-time failures. Admittedly, this
doesn't address the issue of device driver code which has to be written in
assembly, but this is all dreaming anyway.
Path: bga.com!news.sprintlink.net!howland.reston.ans.net!gatech!
bloom-beacon.mit.edu!senator-bedfellow.mit.edu!maze.MIT.EDU!ghudson
From: ghud...@mit.edu (Greg Hudson)
Newsgroups: comp.os.linux.development
Subject: Re: Linux 2 - The Microkernel
Date: 9 Dec 1994 04:02:13 GMT
Organization: Massachvsetts Institvte of Technology
Lines: 45
Message-ID: <3c8ks5$do3@senator-bedfellow.MIT.EDU>
References: <COLLINS.94Nov30150011@zeke.paros.com>
<3bipc6$dl2@uk-usenet.uk.sun.com> <3bovjc$18t@drax.isi.edu>
<newcombe.1064.011D4FBC@aa.csc.peachnet.edu> <3c68v0$ha4@drax.isi.edu>
<3c8bl2$4mo@fido.asd.sgi.com>
NNTP-Posting-Host: maze.mit.edu
X-Newsreader: TIN [version 1.2 PL2]
Larry McVoy (lm@fubar) wrote:
: Ahem. There are two kinds of threads - those that have kernel context
: and those that do not. Everyone should understand by now that user
: level threads /wo kernel context are very fast but basically useless.
: Yes, you can whip out all your esoteric arguments about the wonderful
: things you have done with user level threads, and how select() solves
: all your problems (what about signals, hmm?), and I'll tell you "been
: there, done that, so have dozens of other people, if they are so useful
: how come nobody uses them?).
This is an amazing batch of unsubstantiated claims. A properly designed
user level threads package makes file descriptors and signals work just
as they would using kernel threads. The only serious issues have to do
with delays incurred by file I/O, and that's just a result of a poor
design choice in the Unix environment.
Also, there are quite a number of applications out there using DCE threads,
which is (outside of OSF/1 and HPUX) a user-space threads implementation.
: Threads with kernel level context are basically processes in a shared
: address space. They are somewhat slower but much more useful. You can
: program in that model. Signals work, file descriptors work, etc, etc.
On the contrary, if you've been following the discussion in this newsgroup,
you would find that kernel threads are important for performance reasons
but not for usability reasons.
: : multiple threads than with multiple classic processes. For example,
: : threads just naturally share data space; with processes you have to
: : explicitly map shared memory and allocate your shared data scructures
: : there.
: This is not true in Plan 9 or in IRIX or Sequent's Unix. In all of
: those you get another process that shares (part of) your address space
: and it's just like threads (except signals work and account works and
: ps works and file descriptors work and who knows what else works).
: It's like threads but better. It is threads but better.
I'd like to point out the semantic confusion here: the original poster
was perfectly clear, using the term "classic processes," and you then
went on to contradict him by talking about a very non-classical notion
of processes. Certainly, if your notion of processes encompasses
threads, then you don't need a separate notion of threads, but that's
a rather boring point.
Path: bga.com!news.sprintlink.net!howland.reston.ans.net!swrinde!sgiblab!
sgigate.sgi.com!fido.asd.sgi.com!slovax!lm
From: l...@slovax.engr.sgi.com (Larry McVoy)
Newsgroups: comp.os.linux.development
Subject: Re: Linux 2 - The Microkernel
Date: 10 Dec 1994 22:24:02 GMT
Organization: Silicon Graphics Inc., Mountain View, CA
Lines: 71
Message-ID: <3cd9q2$ns5@fido.asd.sgi.com>
References: <COLLINS.94Nov30150011@zeke.paros.com>
<3bipc6$dl2@uk-usenet.uk.sun.com> <3bovjc$18t@drax.isi.edu>
<newcombe.1064.011D4FBC@aa.csc.peachnet.edu> <3c68v0$ha4@drax.isi.edu>
<3c8bl2$4mo@fido.asd.sgi.com> <3c8ks5$do3@senator-bedfellow.MIT.EDU>
Reply-To: l...@slovax.engr.sgi.com
NNTP-Posting-Host: slovax.engr.sgi.com
X-Newsreader: TIN [version 1.2 PL2]
Greg Hudson (ghud...@mit.edu) wrote:
: Larry McVoy (lm@fubar) wrote:
: : Ahem. There are two kinds of threads - those that have kernel context
: : and those that do not. Everyone should understand by now that user
: : level threads /wo kernel context are very fast but basically useless.
: : Yes, you can whip out all your esoteric arguments about the wonderful
: : things you have done with user level threads, and how select() solves
: : all your problems (what about signals, hmm?), and I'll tell you "been
: : there, done that, so have dozens of other people, if they are so useful
: : how come nobody uses them?).
:
: This is an amazing batch of unsubstantiated claims. A properly designed
: user level threads package makes file descriptors and signals work just
: as they would using kernel threads. The only serious issues have to do
: with delays incurred by file I/O, and that's just a result of a poor
: design choice in the Unix environment.
Yes, it's that last sentence that is crucial. "It all works but it is
kinda slow". That is "kinda useless". People measure things in ones
and tens of microseconds these days, go talk to the people programming
in parallel on the SP2 or TD3, etc, etc.
Further more, if I have a user level threads package, running in a
single process, perhaps you would like to explain how I'm going to get
any parallelism or usefulness out of an MP system?
: Also, there are quite a number of applications out there using DCE threads,
: which is (outside of OSF/1 and HPUX) a user-space threads implementation.
Amounting to exactly how much market share?
: : Threads with kernel level context are basically processes in a shared
: : address space. They are somewhat slower but much more useful. You can
: : program in that model. Signals work, file descriptors work, etc, etc.
: On the contrary, if you've been following the discussion in this newsgroup,
: you would find that kernel threads are important for performance reasons
: but not for usability reasons.
Performance is king. So far, you are failing miserably in your attempt
to convince me that user level threads are worth a damn.
I think the reason I get so wound up about this is that people like you
will start talking about your 2 microsecond context switch time in your
user level threads package. That gets the manager types all hot and
bothered because they think threads are cool. They go off and spend
money and effort only to find that your model sucks on MP, sucks in
complexity, sucks in effort, in short, it sucks. But you talk the talk
and you walk the walk and people, who don't know better, will listen.
You are obviously smart enough to reason this through. Think about it
from the point of view of leading others and start questioning the
basic premise.
: I'd like to point out the semantic confusion here: the original poster
: was perfectly clear, using the term "classic processes," and you then
: went on to contradict him by talking about a very non-classical notion
: of processes. Certainly, if your notion of processes encompasses
: threads, then you don't need a separate notion of threads, but that's
: a rather boring point.
No, that's the whole point. The point is that you only need and want
one implementation of the process abstraction. You may want to adjust
the meaning of that abstraction in terms of sharing of resources and
protection boundries, but you just need one. Threads & processes are
two ways of talking about the same fundemental abstraction that is just
slightly separated on a continuum.
--
---
Larry McVoy (415) 390-1804 l...@sgi.com
Path: bga.com!news.sprintlink.net!howland.reston.ans.net!math.ohio-state.edu!
caen!usenet.coe.montana.edu!bsd.coe.montana.edu!nate
From: n...@bsd.coe.montana.edu (Nate Williams)
Newsgroups: comp.os.linux.development
Subject: Re: Linux 2 - The Microkernel
Date: 10 Dec 1994 23:57:37 GMT
Organization: Montana State University, Bozeman Montana
Lines: 104
Message-ID: <3cdf9h$q8o@pdq.coe.montana.edu>
References: <COLLINS.94Nov30150011@zeke.paros.com> <3c8bl2$4mo@fido.asd.sgi.com>
<3c8ks5$do3@senator-bedfellow.MIT.EDU> <3cd9q2$ns5@fido.asd.sgi.com>
NNTP-Posting-Host: bsd.coe.montana.edu
In article <3cd9q2$...@fido.asd.sgi.com>,
Larry McVoy <l...@slovax.engr.sgi.com> wrote:
>Greg Hudson (ghud...@mit.edu) wrote:
>: Larry McVoy (lm@fubar) wrote:
>: : Ahem. There are two kinds of threads - those that have kernel context
>: : and those that do not. Everyone should understand by now that user
>: : level threads /wo kernel context are very fast but basically useless.
>: : Yes, you can whip out all your esoteric arguments about the wonderful
>: : things you have done with user level threads, and how select() solves
>: : all your problems (what about signals, hmm?), and I'll tell you "been
>: : there, done that, so have dozens of other people, if they are so useful
>: : how come nobody uses them?).
>:
>: This is an amazing batch of unsubstantiated claims. A properly designed
>: user level threads package makes file descriptors and signals work just
>: as they would using kernel threads. The only serious issues have to do
>: with delays incurred by file I/O, and that's just a result of a poor
>: design choice in the Unix environment.
>
>Yes, it's that last sentence that is crucial. "It all works but it is
>kinda slow". That is "kinda useless".
This is starting to get pretty subjective. Should I throw out my 386/25
since "It all works but it is kinda slow". From what you've said, it's
"kinda useless".
>People measure things in ones
>and tens of microseconds these days, go talk to the people programming
>in parallel on the SP2 or TD3, etc, etc.
The only application for threads aren't on Crays. There are plenty of
applications that can benefit from threads on slow, useless hardware
which will make it faster, useless hardware.
>Further more, if I have a user level threads package, running in a
>single process, perhaps you would like to explain how I'm going to get
>any parallelism or usefulness out of an MP system?
What is the percentage of folks that have MP systems? Exactly how much
market share? :)
>: Also, there are quite a number of applications out there using DCE threads,
>: which is (outside of OSF/1 and HPUX) a user-space threads implementation.
>
>Amounting to exactly how much market share?
>
>: : Threads with kernel level context are basically processes in a shared
>: : address space. They are somewhat slower but much more useful. You can
>: : program in that model. Signals work, file descriptors work, etc, etc.
>
>: On the contrary, if you've been following the discussion in this newsgroup,
>: you would find that kernel threads are important for performance reasons
>: but not for usability reasons.
>
>Performance is king. So far, you are failing miserably in your attempt
>to convince me that user level threads are worth a damn.
If 'performance is king' were true most of the computers in the world
wouldn't be PC's.
If 'performance is king' were true GCC wouldn't be one of the most
popular compilers today.
If 'performance is king' the company you are working for wouldn't be
in business after one of the more recent OS releases.
'Usability is king.'
>I think the reason I get so wound up about this is that people like you
>will start talking about your 2 microsecond context switch time in your
>user level threads package. That gets the manager types all hot and
>bothered because they think threads are cool. They go off and spend
>money and effort only to find that your model sucks on MP, sucks in
>complexity, sucks in effort, in short, it sucks. But you talk the talk
>and you walk the walk and people, who don't know better, will listen.
And while you tell him how bad it sucks, he and other will go off and be
using this 'sucky' threads package doing real work while others go off
and try to develop the 'best' solution.
This kind of bigotry is one of the reasons BSD is not as popular today
as Linux is, and you've been quick to point that out. The reason Visual
Basic is so popular today isn't because it's the best solution, but as
one of the bigger *nix and 'C' bigots, it's awful to admit but VB is way
too easy to program in. It works, and it's easy to use. If you want to
develop an application with a slick GUI interface there is nothing I've
seen easier to use.
What's the point? Don't shoot down ideas with 'sucks, sucks, sucks,
sucks' unless you've got something better to replace it with.
We've got quite enough in-fighting around, we don't need to start
attacking people (as I've done, sigh..) and ideas when we don't have
anything better to offer.
Nate
--
n...@bsd.coe.montana.edu | FreeBSD dude and all around tech.
n...@cs.montana.edu | weenie.
work #: (406) 994-5980 | Unemployed, looking for permanant work in
home #: (406) 586-0579 | CS/EE field.
Path: bga.com!news.sprintlink.net!howland.reston.ans.net!swrinde!sgiblab!
sgigate.sgi.com!fido.asd.sgi.com!slovax!lm
From: l...@slovax.engr.sgi.com (Larry McVoy)
Newsgroups: comp.os.linux.development
Subject: Re: Linux 2 - The Microkernel
Date: 11 Dec 1994 01:39:13 GMT
Organization: Silicon Graphics Inc., Mountain View, CA
Lines: 43
Message-ID: <3cdl81$4t1@fido.asd.sgi.com>
References: <COLLINS.94Nov30150011@zeke.paros.com> <3c8bl2$4mo@fido.asd.sgi.com>
<3c8ks5$do3@senator-bedfellow.MIT.EDU> <3cd9q2$ns5@fido.asd.sgi.com>
<3cdf9h$q8o@pdq.coe.montana.edu>
Reply-To: l...@slovax.engr.sgi.com
NNTP-Posting-Host: slovax.engr.sgi.com
X-Newsreader: TIN [version 1.2 PL2]
Nate Williams (n...@bsd.coe.montana.edu) wrote:
: >Yes, it's that last sentence that is crucial. "It all works but it is
: >kinda slow". That is "kinda useless".
: This is starting to get pretty subjective. Should I throw out my 386/25
: since "It all works but it is kinda slow". From what you've said, it's
: "kinda useless".
No, a 386/25 is pretty useful as a mail server or DNS server or X terminal.
Putting threads on it is unlikely to make it much faster though.
: >Further more, if I have a user level threads package, running in a
: >single process, perhaps you would like to explain how I'm going to get
: >any parallelism or usefulness out of an MP system?
: What is the percentage of folks that have MP systems? Exactly how much
: market share? :)
Gimme a break. This is idiotic. Are you actually saying that threads
are primarily for uniprocessor systems? This is mindless flaming.
: And while you tell him how bad it sucks, he and other will go off and be
: using this 'sucky' threads package doing real work while others go off
: and try to develop the 'best' solution.
:
: What's the point? Don't shoot down ideas with 'sucks, sucks, sucks,
: sucks' unless you've got something better to replace it with.
You aren't listening. The whole point was that there is a better
model, Plan 9 has it, among others, it gives you everything you want
and you can implement it in a few days. The point is that people that
want threads would actually be quite happy if they had processes that
shared the address space of the parent. Vfork() where the parent
doesn't block and the child gets a new stack. No new thread specific
API, just the same old stuff you are used too, works on unis, works on
MPs, just kind of works.
It is you Nate, that is flaming without offering a better solution.
I'm flaming worse solutions and pointing people at what I believe to be
the best solution. How about you go read the Plan 9 papers and come
back with a reason why that isn't good enough, or in fact, better than
user level threads?
--
---
Larry McVoy (415) 390-1804 l...@sgi.com
Path: bga.com!news.sprintlink.net!howland.reston.ans.net!spool.mu.edu!
bloom-beacon.mit.edu!senator-bedfellow.mit.edu!maze.MIT.EDU!ghudson
From: ghud...@mit.edu (Greg Hudson)
Newsgroups: comp.os.linux.development
Subject: Re: Linux 2 - The Microkernel
Date: 11 Dec 1994 08:28:56 GMT
Organization: Massachvsetts Institvte of Technology
Lines: 36
Message-ID: <3ced88$gld@senator-bedfellow.MIT.EDU>
References: <COLLINS.94Nov30150011@zeke.paros.com>
<3bipc6$dl2@uk-usenet.uk.sun.com> <3bovjc$18t@drax.isi.edu>
<newcombe.1064.011D4FBC@aa.csc.peachnet.edu> <3c68v0$ha4@drax.isi.edu>
<3c8bl2$4mo@fido.asd.sgi.com> <3c8ks5$do3@senator-bedfellow.MIT.EDU>
<3cd9q2$ns5@fido.asd.sgi.com>
NNTP-Posting-Host: maze.mit.edu
X-Newsreader: TIN [version 1.2 PL2]
Larry McVoy (l...@slovax.engr.sgi.com) wrote:
: I think the reason I get so wound up about this is that people like you
: will start talking about your 2 microsecond context switch time in your
: user level threads package. That gets the manager types all hot and
: bothered because they think threads are cool. They go off and spend
: money and effort only to find that your model sucks on MP, sucks in
: complexity, sucks in effort, in short, it sucks. But you talk the talk
: and you walk the walk and people, who don't know better, will listen.
Is that all? If you review the discussion, you will find that from the
start I've been quite open about admitting that there are performance
issues associated with user-space threads, and that hybrid threads
probably allow you to achieve the best performance (by providing two-level
scheduling, and allowing you to choose between fast context switches and
parallel processing and file I/O).
For many people, parallel file I/O and multiple processors are not big
issues. The X server and the innd part of the INN news server are two
examples of programs implemented as single processes, and they achieve
good performance under most conditions. When you find that you want
really good performance, then sure, you want kernel thread support, but
that shouldn't require changing any of your code if you've been following
the POSIX.4a interface.
If you think in terms of programming for an interface, and using a package
like MIT pthreads as a tool for development (perhaps on platforms that
never will have real thread support; for instance, I do a lot of
development under Ultrix), then you'll probably find user-space threads
much less objectionable. In fact, you may find it convenient to drop
back to user-space threads while debugging, since good debugging tools
for multiple kernel threads aren't very prevalent yet.
(MIT pthreads is moving, albeit slowly, towards hybrid thread support,
so that you can associate an arbitrary number of user-space threads with
each kernel thread.)
Path: bga.com!news.sprintlink.net!hookup!news.mathworks.com!uhog.mit.edu!
bloom-beacon.mit.edu!senator-bedfellow.mit.edu!maze.MIT.EDU!ghudson
From: ghud...@mit.edu (Greg Hudson)
Newsgroups: comp.os.linux.development
Subject: Re: Linux 2 - The Microkernel
Date: 11 Dec 1994 08:46:24 GMT
Organization: Massachvsetts Institvte of Technology
Lines: 43
Message-ID: <3cee90$gld@senator-bedfellow.MIT.EDU>
References: <COLLINS.94Nov30150011@zeke.paros.com>
<3c8bl2$4mo@fido.asd.sgi.com> <3c8ks5$do3@senator-bedfellow.MIT.EDU>
<3cd9q2$ns5@fido.asd.sgi.com> <3cdf9h$q8o@pdq.coe.montana.edu>
<3cdl81$4t1@fido.asd.sgi.com>
NNTP-Posting-Host: maze.mit.edu
X-Newsreader: TIN [version 1.2 PL2]
Larry McVoy (l...@slovax.engr.sgi.com) wrote:
: Gimme a break. This is idiotic. Are you actually saying that threads
: are primarily for uniprocessor systems? This is mindless flaming.
I would argue this, actually. I see threads as a design tool for making
it easy to write modular programs which perform a variety of concurrent
tasks while accessing shared state. Processes with separate address
space make this difficult and expensive; a single-threaded process with
an event-handling loop can introduce latencies and contort the natural
flow of control.
There is the nice side effect that your code can take advantage of
multiple processors, but I've never used a system with more than one
processor myself, despite being an administrator of several network
services, so that's not the biggest motivator for me. (For that
matter, the vast majority of services I deal with are never CPU-bound.)
: You aren't listening. The whole point was that there is a better
: model, Plan 9 has it, among others, it gives you everything you want
: and you can implement it in a few days. The point is that people that
: want threads would actually be quite happy if they had processes that
: shared the address space of the parent. Vfork() where the parent
: doesn't block and the child gets a new stack. No new thread specific
: API, just the same old stuff you are used too, works on unis, works on
: MPs, just kind of works.
I would, indeed, be perfectly happy with Plan 9's model, but I would like
to be able to write code which works for more than one platform. With
the aid of the POSIX.4a draft standard for thread support, I can write
code which works under Ultrix, Linux, NetBSD, Solaris, and probably even
Plan 9. Under Ultrix, Linux, and NetBSD I use the MIT pthreads package;
under Solaris I use macros mapping the POSIX calls onto built-in threads
support, and under Plan 9 I would take a similar approach to Solaris.
Sure, I wind up thinking about "threads" instead of "processes with a
shared address space and file table", but those are really the same
thing, so the distinction doesn't drive the design of any of my
applications.
If it makes you happy, Linux is tending toward the Plan 9 model of thread
support with the clone() call, and MIT pthreads will probably provide a
POSIX.4a interface which takes advantage of clone(). No code to show
for it, though.
Path: bga.com!news.sprintlink.net!howland.reston.ans.net!cs.utexas.edu!
swrinde!sgiblab!sgigate.sgi.com!fido.asd.sgi.com!slovax!lm
From: l...@slovax.engr.sgi.com (Larry McVoy)
Newsgroups: comp.os.linux.development
Subject: Re: Linux 2 - The Microkernel
Date: 11 Dec 1994 20:11:40 GMT
Organization: Silicon Graphics Inc., Mountain View, CA
Lines: 31
Message-ID: <3cfmds$pss@fido.asd.sgi.com>
References: <COLLINS.94Nov30150011@zeke.paros.com>
<3bipc6$dl2@uk-usenet.uk.sun.com> <3bovjc$18t@drax.isi.edu>
<newcombe.1064.011D4FBC@aa.csc.peachnet.edu> <3c68v0$ha4@drax.isi.edu>
<3c8bl2$4mo@fido.asd.sgi.com> <3c8ks5$do3@senator-bedfellow.MIT.EDU>
<3cd9q2$ns5@fido.asd.sgi.com> <3ced88$gld@senator-bedfellow.MIT.EDU>
Reply-To: l...@slovax.engr.sgi.com
NNTP-Posting-Host: slovax.engr.sgi.com
X-Newsreader: TIN [version 1.2 PL2]
Greg Hudson (ghud...@mit.edu) wrote:
: Larry McVoy (l...@slovax.engr.sgi.com) wrote:
: : I think the reason I get so wound up about this is that people like you
: : will start talking about your 2 microsecond context switch time in your
: : user level threads package. That gets the manager types all hot and
: : bothered because they think threads are cool. They go off and spend
: : money and effort only to find that your model sucks on MP, sucks in
: : complexity, sucks in effort, in short, it sucks. But you talk the talk
: : and you walk the walk and people, who don't know better, will listen.
: Is that all? If you review the discussion, you will find that from the
: start I've been quite open about admitting that there are performance
: issues associated with user-space threads, and that hybrid threads
: probably allow you to achieve the best performance (by providing two-level
: scheduling, and allowing you to choose between fast context switches and
: parallel processing and file I/O).
Yeah, that is 1/2 of the main point. I think you underestimate your
influence. When people get up and say "I know about this, and xyz is
the right way, and here are the numbers to prove it", people will
listen. I happen to believe that you can make jumping off a cliff
sound good if all you do is say "you get this wonderful free floating
feeling, it's cool". Smart people have, in my opinion, a
responsibility to tell the whole truth, not just the free falling part
but also the impact part. Engineers tend to be insecure, they rarely
consider that their words have an impact. Especially in the area if
interfaces, you need to be careful what you push. That's all.
--
---
Larry McVoy (415) 390-1804 l...@sgi.com
Path: bga.com!news.sprintlink.net!sundog.tiac.net!max.tiac.net!radics
From: rad...@max.tiac.net (Andras Radics)
Newsgroups: comp.os.linux.development
Subject: Re: Linux 2 - The Microkernel
Date: 12 Dec 1994 02:39:49 GMT
Organization: The Internet Access Company
Lines: 15
Message-ID: <3cgd5l$joe@sundog.tiac.net>
References: <COLLINS.94Nov30150011@zeke.paros.com>
<3c8bl2$4mo@fido.asd.sgi.com> <3c8ks5$do3@senator-bedfellow.MIT.EDU>
<3cd9q2$ns5@fido.asd.sgi.com>
NNTP-Posting-Host: max.tiac.net
["Hmm, I *know* I shouldn't be getting into this..." said our hero as he
felt the pull of the quicksand under his foot.]
A thread can be viewed as a unit of virtual execution (PC, SP, registers),
while a process as the unit of physical resource allocation (cpu time,
memory, files, devices). Viewed in this light, threads and processes are
two orthogonal aspects of program execution, and are not really part of any
continuum.
Also, as with any others, one implementation of these abstractions is just
fine as long as there are no advantages to be gained by creating custom-
tailored ones. (cf.: one implementation of a Turing Machine is just fine
as long as ...)
Andras
Newsgroups: comp.os.linux.development
Path: bga.com!news.sprintlink.net!hookup!nic.ott.hookup.net!ecicrl!
revcan!quantum!danh
From: d...@qnx.com (Dan Hildebrand)
Subject: Re: Linux 2 - The Microkernel
Message-ID: <6q-##htq@qnx.com>
Date: Fri, 09 Dec 94 21:39:58 GMT
Organization: QNX Software Systems
References: <1994Nov30.110346.5280@bay.cc.kcl.ac.uk>
<3c639b$f51@senator-bedfellow.MIT.EDU> <#j+##+q#@qnx.com>
<3c8jae$do3@senator-bedfellow.MIT.EDU>
Lines: 71
In article <3c8jae$...@senator-bedfellow.MIT.EDU>,
Greg Hudson <ghud...@mit.edu> wrote:
>(It's interesting that QNX actually is changing the page table during
>context switches; I had the impression that the QNX context switch times
>commonly tabulated next to other kernels' context switch times were for
>something more like thread context switching than for process context
>switching. Oh, well, serves me right for not doing my homework.)
:-)
Those tabulated comparisons were for the same source code across different
platforms.
>Leaving aside the issue of multiple processors, simply dividing up the
>kernel's servers and putting them on different machines in a network is
>a rather naive way of trying to achieve a distributed operating system,
>unless you're talking about a very small network where you can afford to
>rely on all of the machines being up at a given time.
We provide numerous facilities to detect and recover from machine failures.
For example, if a machine goes down, the network layer in the OS guarantees
that servers on other nodes will get clean close messages from the
processes that were running on the now-dead (or disconnected) machine. We
also include support for multiple LAN links between machines so that you
can load balance the net traffic for better throughput and also route
around failed network links. There are nuclear reactor monitoring systems
and credit card transaction processing systems running QNX with this
technology today. Some customers use backplanes as the processor
interconnect as well. We call this a VLAN (Very Local Area Network).
>Although this may
>be a better start than an integrated kernel, there's still an awful lot
>of work to do before you have a usable system.
Certainly - implementing this technology in a form robust enough for
mission critical applications is not a trivial undertaking.
>(I'm also not convinced that you really want to divide up the kernel.
>Plan 9, an integrated kernel, provides a fair amount of network
>transparency without having machine A rely on machine B for very basic
>things like device drivers and the process table.)
In our architecture, each machine maintains it's own process table and
device drivers. The point is that any process can use any resource on the
net as if it was local. You would find that Plan9 and QNX are roughly
equivalent in network transparency.
>: I doubt you can correct all potential programming errors at compile time.
>: For a mission critical application, being able to intelligently recover
>: from runtime coding errors is a valuable capability.
>
>Certainly, you can't correct all potential programming errors, but you can
>prevent all programming errors of the sort microkernels prevent. With a
>sufficiently good optimizing compiler, you could use a safe language which
>doesn't allow random scribbling over the stack and data segment, and which
>signalled exceptions in the case of run-time failures.
A runtime failure is just another form of memory violation, isn't it? At
least, it probably needs the same types of recovery procedures to kick in
when it happens.
>Admittedly, this
>doesn't address the issue of device driver code which has to be written in
>assembly, but this is all dreaming anyway.
All our device drivers are written in C, and even if you added up the
kernel and device drivers you might find 1% assembly code.
--
Dan Hildebrand d...@qnx.com QNX Software Systems, Ltd.
phone: (613) 591-0931 x204 (voice) 175 Terence Matthews
(613) 591-3579 (fax) Kanata, Ontario, Canada K2M 1W8
Newsgroups: comp.os.linux.development
Path: nntp.gmd.de!Germany.EU.net!howland.reston.ans.net!vixen.cso.uiuc.edu!
uchinews!rumpole.uchicago.edu!user
From: fenst...@cs.uchicago.edu (Kurt D. Fenstermacher)
Subject: Re: Linux 2 - The Microkernel
Message-ID: <fensterm-1312941258500001@rumpole.uchicago.edu>
Sender: n...@uchinews.uchicago.edu (News System)
Organization: Artificial Intelligence Lab, Univ. of Chicago
References: <COLLINS.94Nov30150011@zeke.paros.com>
<3c8bl2$4mo@fido.asd.sgi.com> <3c8ks5$do3@senator-bedfellow.MIT.EDU>
<3cd9q2$ns5@fido.asd.sgi.com> <3cgd5l$joe@sundog.tiac.net>
Date: Tue, 13 Dec 1994 03:58:50 GMT
Lines: 42
In article <3cgd5l$...@sundog.tiac.net>, rad...@max.tiac.net (Andras
Radics) wrote:
> ["Hmm, I *know* I shouldn't be getting into this..." said our hero as he
> felt the pull of the quicksand under his foot.]
I'm getting that sinking feeling myself....
> A thread can be viewed as a unit of virtual execution (PC, SP, registers),
> while a process as the unit of physical resource allocation (cpu time,
> memory, files, devices). Viewed in this light, threads and processes are
> two orthogonal aspects of program execution, and are not really part of any
> continuum.
I'm not sure that: 1) this is a valid distinction between threads and
processes, and 2) if it were that it would imply orthogonality. What do
you mean by virtual execution? A thread is a flow of control with its own
machine instructions, function calls, etc....
Are you suggesting that CPU time, files and devices can't be independently
allocated to threads within a process? Perhaps you're thinking strictly
of user-level threads, and not kernel-level threads? An O/S with
kernel-level threading can schedule threads individually, and a single
thread can block on file I/O without blocking the entire process. The
common terms "heavyweight process" (for what most people think of as a
process) and "lightweight process" for threads do imply the continuum that
others have been talking about.
> Also, as with any others, one implementation of these abstractions is just
> fine as long as there are no advantages to be gained by creating custom-
> tailored ones. (cf.: one implementation of a Turing Machine is just fine
> as long as ...)
I don't think anyone's arguing that one thread model, or kernel
architecture is computationally more powerful than another. It's really a
discussion about (or it should be about) the question: what services
should Linux provide? To put it in your terms, the difference between
user- and kernel-level threads, or microkernel vs. integrated kernel is
about which implementation is easier to custom-tailor.
--
Kurt D. Fenstermacher
"Idle lawyers tend to become politicians, so there is a certain social value
in keeping lawyers busy."
- Operating Systems Concepts, Silberschatz & Galvin
Newsgroups: comp.os.linux.development
Path: nntp.gmd.de!newsserver.jvnc.net!nntpserver.pppl.gov!princeton!udel!
gatech!howland.reston.ans.net!pipex!uknet!info!iialan
From: iia...@iifeak.swan.ac.uk (Alan Cox)
Subject: Re: Linux 2 - The Microkernel
Message-ID: <D0r7oI.AML@info.swan.ac.uk>
Sender: n...@info.swan.ac.uk
Nntp-Posting-Host: iifeak.swan.ac.uk
Organization: Institute For Industrial Information Technology
References: <3bu4g8$qsv@pdq.coe.montana.edu> <D0GKEy.DKy@info.swan.ac.uk>
<3c5md3$t3g@pdq.coe.montana.edu>
Date: Tue, 13 Dec 1994 14:45:54 GMT
Lines: 53
In article <3c5md3$...@pdq.coe.montana.edu> n...@bsd.coe.montana.edu
(Nate Williams) writes:
>them there. There are fast MK implementations out there which are as
>fast or faster than almost all of the free IK's who do most of the
>work outside of the 'kernel'.
I've not seen any.
>>I can anyway. Linux has user mode file systems, loadable file systems,
>>loadable networking stacks. It doesn't have a loadable scheduler but
>>then changing scheduler on the fly will be fun...
>It's still in the kernel, and if you hose up the FS you've completely
>hosed up the kernel as well. If you screw up a server stack, then
No the user mode file system is as its name suggests in user mode. You
can run user mode networking stacks (eg CAP) under Linux or *BSD.
>Show me *one* well structured IK. Linux is understandable, but for the
>average user they can't understand the complexity of the entire thing.
>Joe average programmers relies on the talents of Linus and the others
>to handle the 'big picture'. This doesn't have to be the case.
No it relies on the fact you don't need to understand the big picture. I've
no idea how many of the innards of things like ext2fs work. I never want to
have much idea either. I think the same is true of BSD also. A microkernel
is no different although a bit more formalised.
>Let's see you fit Linux on a 1MB machine and have it perform useful
>tasks.
Done it. Ok so the useful task was rogue 8). It does useful things in 2Mb
if you tune it well (and avoid stuff like bash and gcc [vomit]). The big
killer here is "applications" as opposed to the good unix idea of a set
of small commands (I guess unix commands are message(pipe) passing
microapplications 8)). I could do it with current kernels too except that
the boot loader now uses 2Mb of ram for the compressed kernel
stuff.
>Read the literature. 'Micro-kernel' has never meant small in size. It
>means small in functionality. And, this 'portability' issue is espoused
Makes mach look even worse, so its bloated low functionality 8). I have
seen reasonable microkernel architectures like the Amiga Exec. I've also
seen the problems they cause. I don't count mach as a microkernel its too
full of 'clever' ideas that don't actually seem to work out neat. At least
the Amiga Exec and QNX have a useful small core and while I cant answer the
QNX figures for a message pass the amiga one was about 100 instructions.
Alan
--
..-----------,,----------------------------,,----------------------------,,
// Alan Cox // iia...@www.linux.org.uk // GW4PTS@GB7SWN.#45.GBR.EU //
``----------'`--[Anti Kibozing Signature]-'`----------------------------''
One two three: Kibo, Lawyer, Refugee :: Green card, Compaq come read me...
Newsgroups: comp.os.linux.development
Path: nntp.gmd.de!newsserver.jvnc.net!nntpserver.pppl.gov!princeton!rutgers!
sgigate.sgi.com!enews.sgi.com!lll-winken.llnl.gov!sol.ctr.columbia.edu!
howland.reston.ans.net!swrinde!pipex!uknet!info!iialan
From: iia...@iifeak.swan.ac.uk (Alan Cox)
Subject: Re: Linux 2 - The Microkernel
Message-ID: <D0t87H.560@info.swan.ac.uk>
Sender: n...@info.swan.ac.uk
Nntp-Posting-Host: iifeak.swan.ac.uk
Organization: Institute For Industrial Information Technology
References: <3c13jg$cdb@agate.berkeley.edu> <3c3dm8$gst@usenet.srv.cis.pitt.edu>
<3c65c4$ov7@galaxy.ucr.edu>
Date: Wed, 14 Dec 1994 16:52:28 GMT
Lines: 26
In article <3c65c4$...@galaxy.ucr.edu> cvar...@corsa.ucr.edu (Curtis Varner)
writes:
> Also, unless you do all the forks initially (such as in many
>implementations of nfsd), you pay a big hit in performance, as forks
>are more expensive than creating a thread. Now that I think about it,
You still take a hit on most architectures as your fork()ed process
has a different page table and thus you keep trashing your page table
cache.
>a multithreaded program would use less memory/system resources than
>multiple children would. I would say that the fork/exec memory style
>is okay if you don't have access to threads - but use the threads if
>you got them.
All the multithreaded stuff I've worked with is user level threads
(mis)using longjmp/setjmp and careful use of I/O - works well enough for
what I've wanted.
Alan
--
..-----------,,----------------------------,,----------------------------,,
// Alan Cox // iia...@www.linux.org.uk // GW4PTS@GB7SWN.#45.GBR.EU //
``----------'`--[Anti Kibozing Signature]-'`----------------------------''
One two three: Kibo, Lawyer, Refugee :: Green card, Compaq come read me...
Path: nntp.gmd.de!newsserver.jvnc.net!nntpserver.pppl.gov!princeton!rutgers!
sgigate.sgi.com!enews.sgi.com!lll-winken.llnl.gov!sol.ctr.columbia.edu!
howland.reston.ans.net!gatech!psuvax1!psuvax1.cse.psu.edu!schwartz
From: schwa...@roke.cse.psu.edu (Scott Schwartz)
Newsgroups: comp.os.linux.development
Subject: Re: Linux 2 - The Microkernel
Date: 14 Dec 1994 23:08:49 GMT
Organization: Penn State Comp Sci & Eng
Lines: 21
Message-ID: <SCHWARTZ.94Dec14180849@roke.cse.psu.edu>
References: <COLLINS.94Nov30150011@zeke.paros.com> <3c8bl2$4mo@fido.asd.sgi.com>
<3c8ks5$do3@senator-bedfellow.MIT.EDU> <3cd9q2$ns5@fido.asd.sgi.com>
<3cgd5l$joe@sundog.tiac.net>
<fensterm-1312941258500001@rumpole.uchicago.edu>
NNTP-Posting-Host: roke.cse.psu.edu
In-reply-to: fensterm@cs.uchicago.edu's message of Tue, 13 Dec 1994 03:58:50 GMT
fenst...@cs.uchicago.edu (Kurt D. Fenstermacher) writes:
In article <3cgd5l$...@sundog.tiac.net>, rad...@max.tiac.net (Andras
Radics) wrote:
> A thread can be viewed as a unit of virtual execution (PC, SP, registers),
> while a process as the unit of physical resource allocation (cpu time,
> memory, files, devices).
I'm not sure that: 1) this is a valid distinction between threads and
processes, and 2) if it were that it would imply orthogonality.
Andras is offering the view of these things as understood in Mach. In
contrast, in Plan 9 a thread of control is called a "process", and it
is created with "rfork". A (bitmask) parameter to rfork indicates
what qualities (data segment, signals, file descriptors, etc) the
newly created process is to share with its parent or to be allocated
afresh. It's a flexible, elegant, and efficient way to do things.
Fork need not be slow, if you implement it well. On an SGI Challenge,
Rob Pike reports that 10,000 fork/exit/wait calls take 41.1 seconds
under Irix and 1.32 seconds under Plan 9.
Path: nntp.gmd.de!newsserver.jvnc.net!news.cac.psu.edu!news.pop.psu.edu!
psuvax1!uwm.edu!news.moneng.mei.com!hookup!olivea!sgigate.sgi.com!
fido.asd.sgi.com!slovax!lm
From: l...@slovax.engr.sgi.com (Larry McVoy)
Newsgroups: comp.os.linux.development
Subject: Re: Linux 2 - The Microkernel
Date: 15 Dec 1994 06:57:54 GMT
Organization: Silicon Graphics Inc., Mountain View, CA
Lines: 17
Message-ID: <3copdi$na6@fido.asd.sgi.com>
References: <3c13jg$cdb@agate.berkeley.edu>
<3c3dm8$gst@usenet.srv.cis.pitt.edu> <3c65c4$ov7@galaxy.ucr.edu>
<D0t87H.560@info.swan.ac.uk>
Reply-To: l...@slovax.engr.sgi.com
NNTP-Posting-Host: slovax.engr.sgi.com
X-Newsreader: TIN [version 1.2 PL2]
Alan Cox (iia...@iifeak.swan.ac.uk) wrote:
: In article <3c65c4$...@galaxy.ucr.edu> cvar...@corsa.ucr.edu (Curtis Varner)
writes:
: > Also, unless you do all the forks initially (such as in many
: >implementations of nfsd), you pay a big hit in performance, as forks
: >are more expensive than creating a thread. Now that I think about it,
: You still take a hit on most architectures as your fork()ed process
: has a different page table and thus you keep trashing your page table
: cache.
This is the only legitimate argument against the Plan 9 model of threads.
I'll go check and see if SGI figured out a way around this; I don't think
they did.
--
---
Larry McVoy (415) 390-1804 l...@sgi.com
Path: nntp.gmd.de!newsserver.jvnc.net!darwin.sura.net!rsg1.er.usgs.gov!
jobone!newsxfer.itd.umich.edu!gatech!taco.cc.ncsu.edu!slblake
From: slbl...@eos.ncsu.edu (Steven L Blake)
Newsgroups: comp.os.linux.development
Subject: Re: Linux 2 - The Microkernel
Date: 15 Dec 1994 15:43:55 GMT
Organization: NCSU Center for Communications and Signal Processing
Lines: 24
Message-ID: <3cpo7r$kal@taco.cc.ncsu.edu>
References: <3cgd5l$joe@sundog.tiac.net>
<fensterm-1312941258500001@rumpole.uchicago.edu>
<SCHWARTZ.94Dec14180849@roke.cse.psu.edu>
NNTP-Posting-Host: c11056-312dan.ece.ncsu.edu
In article <SCHWARTZ.94Dec14180...@roke.cse.psu.edu> schwa...@roke.cse.psu.edu
(Scott Schwartz) writes:
>Andras is offering the view of these things as understood in Mach. In
>contrast, in Plan 9 a thread of control is called a "process", and it
>is created with "rfork". A (bitmask) parameter to rfork indicates
>what qualities (data segment, signals, file descriptors, etc) the
>newly created process is to share with its parent or to be allocated
>afresh. It's a flexible, elegant, and efficient way to do things.
>
>Fork need not be slow, if you implement it well. On an SGI Challenge,
>Rob Pike reports that 10,000 fork/exit/wait calls take 41.1 seconds
>under Irix and 1.32 seconds under Plan 9.
What is Plan 9 doing (or not doing) that results in a 30:1 speedup
of fork/exec/wait()?
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| Steven L. Blake slbl...@eos.ncsu.edu |
| NC State University (919)515-3916 |
| Center for Communications and Signal Processing |
| Fiber to the curb, with 25 Mbps ATM over twisted pair |
| to the home. I want mine _today_! |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Path: nntp.gmd.de!newsserver.jvnc.net!news.cac.psu.edu!news.pop.psu.edu!
psuvax1!psuvax1.cse.psu.edu!schwartz
From: schwa...@roke.cse.psu.edu (Scott Schwartz)
Newsgroups: comp.os.linux.development
Subject: Re: Linux 2 - The Microkernel
Date: 15 Dec 1994 16:57:01 GMT
Organization: Penn State Comp Sci & Eng
Lines: 8
Message-ID: <SCHWARTZ.94Dec15115701@roke.cse.psu.edu>
References: <3cgd5l$joe@sundog.tiac.net>
<fensterm-1312941258500001@rumpole.uchicago.edu>
<SCHWARTZ.94Dec14180849@roke.cse.psu.edu> <3cpo7r$kal@taco.cc.ncsu.edu>
NNTP-Posting-Host: roke.cse.psu.edu
In-reply-to: slblake@eos.ncsu.edu's message of 15 Dec 1994 15:43:55 GMT
slbl...@eos.ncsu.edu (Steven L Blake) writes:
What is Plan 9 doing (or not doing) that results in a 30:1 speedup
of fork/exec/wait()?
If you'll forgive a nontechnical answer, I think the main thing is
simply that it is being written by people who think that small and
fast is important. (Nice hardware helps too. Sparc gets a much
smaller speedup.)
Path: nntp.gmd.de!newsserver.jvnc.net!news.cac.psu.edu!news.pop.psu.edu!
psuvax1!uwm.edu!news.alpha.net!solaris.cc.vt.edu!swiss.ans.net!gatech!
taco.cc.ncsu.edu!slblake
From: slbl...@eos.ncsu.edu (Steven L Blake)
Newsgroups: comp.os.linux.development
Subject: Re: Linux 2 - The Microkernel
Date: 15 Dec 1994 17:19:36 GMT
Organization: NCSU Center for Communications and Signal Processing
Lines: 37
Message-ID: <3cptr8$lur@taco.cc.ncsu.edu>
References: <SCHWARTZ.94Dec14180849@roke.cse.psu.edu>
<3cpo7r$kal@taco.cc.ncsu.edu> <SCHWARTZ.94Dec15115701@roke.cse.psu.edu>
NNTP-Posting-Host: c11056-312dan.ece.ncsu.edu
In article <SCHWARTZ.94Dec15115...@roke.cse.psu.edu> schwa...@roke.cse.psu.edu
(Scott Schwartz) writes:
>slbl...@eos.ncsu.edu (Steven L Blake) writes:
> What is Plan 9 doing (or not doing) that results in a 30:1 speedup
> of fork/exec/wait()?
>
>If you'll forgive a nontechnical answer, I think the main thing is
>simply that it is being written by people who think that small and
>fast is important. (Nice hardware helps too. Sparc gets a much
>smaller speedup.)
Meaning that:
1) Plan 9 doesn't run as well on Sparc as on MIPS?
-or-
2) SunOS/Solaris is better optimized at fork/exec/wait() than IRIX?
I'm confused. The point of the question was to see if there was something
that SGI or Sun could do to speed up their implementations (save switching
to Plan 9. :) Neither Solaris nor IRIX are small, but it seems that if
they are so dramatically slower then Plan 9, then they are either poorly
designed, poorly coded, or that they are implementing some additional
functionality that precludes a simple speedup. Both Solaris and IRIX
are multi-threaded SMP kernels (meaning that they require a substantial
number of locks on kernel data structures); is Plan 9?
PS. You're certainly forgiven. :)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| Steven L. Blake slbl...@eos.ncsu.edu |
| NC State University (919)515-3916 |
| Center for Communications and Signal Processing |
| Fiber to the curb, with 25 Mbps ATM over twisted pair |
| to the home. I want mine _today_! |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Path: nntp.gmd.de!Germany.EU.net!howland.reston.ans.net!gatech!psuvax1!
psuvax1.cse.psu.edu!schwartz
From: schwa...@roke.cse.psu.edu (Scott Schwartz)
Newsgroups: comp.os.linux.development
Subject: Re: Linux 2 - The Microkernel
Date: 15 Dec 1994 19:50:32 GMT
Organization: Penn State Comp Sci & Eng
Lines: 53
Message-ID: <SCHWARTZ.94Dec15145032@roke.cse.psu.edu>
References: <SCHWARTZ.94Dec14180849@roke.cse.psu.edu> <3cpo7r$kal@taco.cc.ncsu.edu>
<SCHWARTZ.94Dec15115701@roke.cse.psu.edu> <3cptr8$lur@taco.cc.ncsu.edu>
NNTP-Posting-Host: roke.cse.psu.edu
In-reply-to: slblake@eos.ncsu.edu's message of 15 Dec 1994 17:19:36 GMT
I meant to say that for this microbenchmark sparc is slower than mips,
regardless of operating system (and also that plan 9 is faster than
the native os.)
You could argue that just timing fork/exit/wait isn't the whole story
with respect to kernel performance, which is definately true, but it
does measure at least part of what this argument was about when I
jumped in.
I'm confused. The point of the question was to see if there was something
that SGI or Sun could do to speed up their implementations (save switching
to Plan 9. :) Neither Solaris nor IRIX are small, but it seems that if
they are so dramatically slower then Plan 9, then they are either poorly
designed, poorly coded, or that they are implementing some additional
functionality that precludes a simple speedup.
Someone with access to Solaris or IRIX source will have to answer that
question. I'm not familiar enough with the internals of these systems
to give you a scholarly assessment.
Since this is a linux newsgroup, I thought the point of the question
was to see if linux could get better functionality ("threads") without
becoming big and complex and slow. Choosing the right primatives is a
part of this. Instead of trying to wedge Mach style abstractions into
a Unix style kernel, why not do something that fits more naturally,
like rfork.
Both Solaris and IRIX are multi-threaded SMP kernels (meaning that
they require a substantial number of locks on kernel data
structures); is Plan 9?
Yes, Plan 9 is SMP.
Here's the code, if someone wants to time it on their linux system.
/*
#include <u.h>
#include <libc.h>
#define exit exits
*/
main()
{
int i;
for (i=0; i<10000; ++i) {
if (fork()) {
wait(0);
} else {
exit(0);
}
}
}
Path: nntp.gmd.de!newsserver.jvnc.net!howland.reston.ans.net!swrinde!
sgiblab!sgigate.sgi.com!fido.asd.sgi.com!fubar!lm
From: lm@fubar (Larry McVoy)
Newsgroups: comp.os.linux.development
Subject: Re: Linux 2 - The Microkernel
Date: 15 Dec 1994 23:52:10 GMT
Organization: Silicon Graphics Inc., Mountain View, CA
Lines: 70
Message-ID: <3cqkra$gd0@fido.asd.sgi.com>
References: <SCHWARTZ.94Dec14180849@roke.cse.psu.edu>
<3cpo7r$kal@taco.cc.ncsu.edu> <SCHWARTZ.94Dec15145032@roke.cse.psu.edu>
Reply-To: l...@slovax.engr.sgi.com
NNTP-Posting-Host: fubar.engr.sgi.com
X-Newsreader: TIN [version 1.2 PL1]
Scott Schwartz (schwa...@roke.cse.psu.edu) wrote:
: Here's the code, if someone wants to time it on their linux system.
It already has been. I have the same benchmark as one of the tests in
lmbench. I call this the "Null process" benchmark in the table below.
The Plan 9 numbers converted to the same format are 132. The average
real Unix numbers are ~3000 vs Plan 9's 132. Plan 9 must be pretty
quick. I suspect that quickness is not without cost.
L M B E N C H 1 . 0 S U M M A R Y
------------------------------------
Processor, Processes - times in microseconds
--------------------------------------------
Host OS Mhz Null Null Simple /bin/sh Mmap 2-proc 8-proc
Syscall Process Process Process lat ctxsw ctxsw
--------- ------------- ---- ------- ------- ------- ------- ---- ------ ------
rs6000 AIX 2 62 23 2.0K 7.3K 23K 3817 20 32
seahorse HP-UX A.09.03 99 14 3.6K 10.1K 18K 116 25 29
snake HP-UX A.09.01 66 21 2.6K 5.7K 17K 156 47 55
IP22 IRIX 5.3 198 11 3.1K 8.0K 19K 260 40 38
pentium Linux 1.1.54 91 3 3.3K 15.4K 49K 33 66 94
alpha OSF1 V2.1 182 13 4.8K 16.1K 43K 172 25 42
ss20.50 SunOS 5.4 50 9 10.7K 57.5K 113K 130 54 85
ss20.61 SunOS 5.4 61 7 8.0K 45.8K 87K 104 37 52
*Local* Communication latencies in microseconds
-----------------------------------------------
Host OS Pipe UDP RPC/ TCP RPC/
UDP TCP
--------- ------------- ------- ------- ------- ------- -------
rs6000 AIX 2 143 385 820 498 1054
seahorse HP-UX A.09.03 193 244 832 262 812
snake HP-UX A.09.01 296 403 1195 367 1142
IP22 IRIX 5.3 131 313 671 278 641
pentium Linux 1.1.54 157 658 1030 1164 1591
alpha OSF1 V2.1 185 404 718 428 851
ss20.50 SunOS 5.4 194 590 935 560 1196
ss20.61 SunOS 5.4 150 414 622 335 784
*Local* Communication bandwidths in megabytes/second
----------------------------------------------------
Host OS Pipe TCP File Mmap Bcopy Bcopy Mem Mem
reread reread (libc) (hand) read write
--------- ------------- ---- ---- ------ ------ ------ ------ ---- -----
rs6000 AIX 2 34 6.0 76.1 63.0 81 120 99 169
seahorse HP-UX A.09.03 38 35.2 44.7 32.1 25 31 49 52
snake HP-UX A.09.01 19 17.8 34.4 22.3 22 24 45 39
IP22 IRIX 5.3 34 22.1 32.3 43.7 32 31 69 66
pentium Linux 1.1.54 13 2.4 9.8 4.7 18 18 48 32
alpha OSF1 V2.1 32 12.1 39.4 22.7 39 41 76 78
ss20.50 SunOS 5.4 11 11.0 22.9 30.0 26 31 80 62
ss20.61 SunOS 5.4 24 19.5 31.0 30.7 23 24 59 40
Memory latencies in nanoseconds
(WARNING - may not be correct, check graphs)
--------------------------------------------
Host OS Mhz L1 $ L2 $ Main mem TLB Guesses
--------- ------------- --- ---- ---- -------- --- -------
rs6000 AIX 2 61 15 229 247 776 No L2 cache?
seahorse HP-UX A.09.03 98 10 10 393 481 No L1 cache?
snake HP-UX A.09.01 65 15 15 378 1051 No L1 cache?
IP22 IRIX 5.3 197 10 76 1018 1129
pentium Linux 1.1.54 90 11 294 439 1254
alpha OSF1 V2.1 182 10 56 321 452
ss20.50 SunOS 5.4 49 20 284 291 575 No L2 cache?
ss20.61 SunOS 5.4 60 16 115 816 961
--
---
Larry McVoy (415) 390-1804 l...@sgi.com
Path: nntp.gmd.de!newsserver.jvnc.net!nntpserver.pppl.gov!princeton!rutgers!
sgigate.sgi.com!enews.sgi.com!lll-winken.llnl.gov!sol.ctr.columbia.edu!
howland.reston.ans.net!swiss.ans.net!fonorola!achilles!achilles!not-for-mail
From: pjlah...@achilles.net (Paul JY Lahaie)
Newsgroups: comp.os.linux.development
Subject: Re: Linux 2 - The Microkernel
Date: 14 Dec 1994 18:02:58 -0500
Organization: Achilles Internet Limited, Nepean, ON
Lines: 30
Message-ID: <3cntj2$dc6@zeus.achilles.net>
References: <1994Nov30.110346.5280@bay.cc.kcl.ac.uk> <#j+##+q#@qnx.com>
<3c8jae$do3@senator-bedfellow.MIT.EDU> <6q-##htq@qnx.com>
NNTP-Posting-Host: zeus.achilles.net
In article <6q-##...@qnx.com>, Dan Hildebrand <d...@qnx.com> wrote:
>Those tabulated comparisons were for the same source code across different
>platforms.
Where can one get this source code? I want to see if Linux with the
sched patches will perform better.
>processes that were running on the now-dead (or disconnected) machine. We
>also include support for multiple LAN links between machines so that you
>can load balance the net traffic for better throughput and also route
>around failed network links. There are nuclear reactor monitoring systems
Except IRQ7 Arcnet cards right? :-) Got bitten bad by that at EntreNet
Systems.
>All our device drivers are written in C, and even if you added up the
>kernel and device drivers you might find 1% assembly code.
Speaking of C, any ideas on how to get wcc code from QNX to Linux? It
is my understanding that Watcom does a slightly better job of optimizing
than GCC, and it would be nice to use the extra optimizations on my P60.
(Especially considering there's no good GCC with Pentium support).
- Paul
--
Paul JY Lahaie Internet: pjlah...@achilles.net
Achilles Internet
Director of Technical Operations
Newsgroups: comp.os.linux.development
Path: nntp.gmd.de!newsserver.jvnc.net!news.cac.psu.edu!news.pop.psu.edu!
hudson.lm.com!godot.cc.duq.edu!news.duke.edu!news.mathworks.com!
uhog.mit.edu!bloom-beacon.mit.edu!spool.mu.edu!torn!nott!cunews!revcan!
quantum!danh
From: d...@qnx.com (Dan Hildebrand)
Subject: Re: Linux 2 - The Microkernel
Message-ID: <6hh##nt+@qnx.com>
Date: Sat, 17 Dec 94 17:45:10 GMT
Organization: QNX Software Systems
References: <1994Nov30.110346.5280@bay.cc.kcl.ac.uk>
<3c8jae$do3@senator-bedfellow.MIT.EDU> <6q-##htq@qnx.com>
<3cntj2$dc6@zeus.achilles.net>
Lines: 39
In article <3cntj2$...@zeus.achilles.net>,
Paul JY Lahaie <pjlah...@achilles.net> wrote:
>In article <6q-##...@qnx.com>, Dan Hildebrand <d...@qnx.com> wrote:
>
>>Those tabulated comparisons were for the same source code across different
>>platforms.
>
> Where can one get this source code? I want to see if Linux with the
>sched patches will perform better.
My understanding is that Larry McVoy prefers that the source not be
distributed any longer because it doesn't properly measure just context
switches, given the signal manipulation also going on. Besides, his new
benchmark code is so much better. :-)
>>processes that were running on the now-dead (or disconnected) machine. We
>>also include support for multiple LAN links between machines so that you
>>can load balance the net traffic for better throughput and also route
>>around failed network links. There are nuclear reactor monitoring systems
>
> Except IRQ7 Arcnet cards right? :-) Got bitten bad by that at EntreNet
>Systems.
Bad hardware is bad hardware. :-)
>>All our device drivers are written in C, and even if you added up the
>>kernel and device drivers you might find 1% assembly code.
>
> Speaking of C, any ideas on how to get wcc code from QNX to Linux? It
>is my understanding that Watcom does a slightly better job of optimizing
>than GCC, and it would be nice to use the extra optimizations on my P60.
>(Especially considering there's no good GCC with Pentium support).
WCC generates Intel-Microsoft standard object files. If you have the
tools to turn them into something gcc can use, then you're all set. :-)
--
Dan Hildebrand d...@qnx.com QNX Software Systems, Ltd.
phone: (613) 591-0931 x204 (voice) 175 Terence Matthews
(613) 591-3579 (fax) Kanata, Ontario, Canada K2M 1W8
Path: nntp.gmd.de!newsserver.jvnc.net!netnews.upenn.edu!msunews!uwm.edu!
cs.utexas.edu!swrinde!sgiblab!sgigate.sgi.com!fido.asd.sgi.com!slovax!lm
From: l...@slovax.engr.sgi.com (Larry McVoy)
Newsgroups: comp.os.linux.development
Subject: Re: Linux 2 - The Microkernel
Date: 18 Dec 1994 04:46:06 GMT
Organization: Silicon Graphics Inc., Mountain View, CA
Lines: 34
Message-ID: <3d0eqe$bka@fido.asd.sgi.com>
References: <1994Nov30.110346.5280@bay.cc.kcl.ac.uk>
<3c8jae$do3@senator-bedfellow.MIT.EDU> <6q-##htq@qnx.com>
<3cntj2$dc6@zeus.achilles.net> <6hh##nt+@qnx.com>
Reply-To: l...@slovax.engr.sgi.com
NNTP-Posting-Host: slovax.engr.sgi.com
X-Newsreader: TIN [version 1.2 PL2]
Dan Hildebrand (d...@qnx.com) wrote:
: In article <3cntj2$...@zeus.achilles.net>,
: Paul JY Lahaie <pjlah...@achilles.net> wrote:
: >In article <6q-##...@qnx.com>, Dan Hildebrand <d...@qnx.com> wrote:
: >
: >>Those tabulated comparisons were for the same source code across different
: >>platforms.
: >
: > Where can one get this source code? I want to see if Linux with the
: >sched patches will perform better.
:
: My understanding is that Larry McVoy prefers that the source not be
: distributed any longer because it doesn't properly measure just context
: switches, given the signal manipulation also going on. Besides, his new
: benchmark code is so much better. :-)
The story behind this is this: I wrote a little benchmark that forced
ctx switches by using signals. I ran that and got a bunch other people
to run that benchmark on various systems and the results appeared here
and other places.
As Dan said, that benchmark was pretty flawed since it included the signal
overhead which is substantial.
The lmbench sources include a much better context switch benchmark that
is
a) much more accurate, and
b) shows results for varying numbers of various sized processes.
That latter is fairly useful for seeing how well a multi threaded application
might work on your hardware.
--
---
Larry McVoy (415) 390-1804 l...@sgi.com