[Sussex] LINUX takes on XServe

[Steve Dobson]

Geoff

Finally managed to un-wind my e-mail stack to get to this one :-)

On 31 October 2002 08:39 Geoff Teale wrote:
> This is an interesting debate.

Yes I though so too.

>                                 I had assumed that OS X was using a
> microkernel because it was based on Mach.  Seems I was wrong.. :)

I share your wrongness - does this mean that on averaged we weren't so
wrong (I think not :-)

> It does sound like this is definitely not a microkernel,

Yes I though so in my posting yesterday.

>                                                          although the
> central architecure may be the same as one.

Point of order:  How can the central architecture be the same?
In a microkernel you move everything you possibly can out to user-
land and provide an (efficient) inter-process communication system
[AmigaOS].  My argument (such that it is) is that if the kernel
isn't minimal then it must be a monolickernel regardless of the
user-/kernel-land APIs.

>                                              This kind of hybrid
> (suddenly the Darwin platypus makes sense) seems a bit clunky really, 
> but can have certain advantages.

The primary one in my mind is that messages are going to be processed
in order.

>                                  I'd take a bet that the Apple engineers
> prefer the internal architecture of Mach to that of BSD.

No bet!

> Of course performance wise you'll still take a lot of the 
> hits of a normal microkernel (because the mechanisms required
> will mostly be the same), although you reduce the number of
> context switches.

Not sure that I agree.  In a microkernel I would expect four
context switches to perform the equivalent of a Unix system call.

   Client post a message
      1). Context switch from userland to kernelland.
   Kernel routes message
      2). Context switch from kernelland to userland.
   Server gets message, processes it and send response.
      3). Context switch from userland to kernelland.
   Kernel routes response.
      4). Context switch from kernelland to userland.
   Client gets response.

For Unix (and other "pure" monolithic kernels)

   Application makes a system call.
      1). Context switch from userland to kernelland.
   Kernel get system call data, processes it and responds.
      2). Context switch from kernelland to userland.
   Application gets system response.

As the context switch is very expensive for "simple" system
calls this could be lion's share of the work.  From a lot 
of work done minimising context switches goes a long way to
system performance.
 
> All of this remind me of Windows NT.  NT famously started out 
> as a pure Microkernel and was actually a fairly stable product,
> however custromers complained that it was slow (it really was
> very very slow) so for NT 4 they re-engineered it to reduce
> the time taken for interface calls - the way they achieved
> this was by moving almost all of the OS functionality back
> into the kernel.  They got a significant speed increase but they 
> resulted in a flaky OS (hence the problems with all subsequent
> NT versions.. including 2000 and XP).  
>
> Theoretically all microkernels should be more reliable than
> Monolithic kernels.  In reality a well written microkernel
> is easier to maintain without introducing bugs (because of
> the seperation of functionality via interfaces and the fact
> that most OS functionality runs in protected memory) but most
> Unicies are living proof that Monolithic architecures can be made
> to be very stable.  

There are two reasons for this:
  
  *) The smaller a program is the less there is to go wrong, and

  *) If you're using protected memory applications can't corrupt
     each others (or the kernels) memory.  This one application
     crash doesn't kill the whole machine.  Here there is only one
     program the can do that; the kernel.
 
> Equally there are microkernels out there that disprove the rule that
> Monolithic kernels are faster - but the generel case is true.

Agreed
 
> Tony wrote:
> -----------
> > However, micro or macro, it doesn't invalidate Geoff's point that a 
> > monolithic kernel is normally faster than a microkernel, presumably 
> > because of the clock cycles spent on passing the layers?
> 
> Yup, context switching, lack of caching in the kernel.. etc, etc..

Ohhhh, it took me much longer to say the same thing.  I must like 
hearing myself type :-)
 
<snip>

Steve