On Thu, Sep 01, 2005 at 10:05:40PM +1000, QuantumG wrote:
> [EMAIL PROTECTED] wrote:
>
> >Don't forget that a microkernel introduces communication overhead and
> >usually some extra scheduling overhead which in turn eats into performance.
> >I seem to remember there was a big squabble over who had the fastest
> >webserver until Linux introduced a kernel level http accelerator which
> >blew everyone else out of the water so badly that they first tried accusing
> >the kernel developers of cheating and when that didn't work they just
> >stopped playing that game, took the ball and went home.
> >
> >
>
> That's because it's a stupid idea. Really, it is.
Really, Linux kicked everyone's backside. Really it did. Runs on the board.
You may argue that the test was unrealistic in the first place, and many
people would agree with you, but FOR BEATING THAT TEST it was a good strategy.
> We can put all the
> code of the entire system into one process and run it in ring-0 and
> we'll have the fastest system in the world!
Setting every priority to mostest is a common strategy in Australian
management circles but it doesn't actually make things get done faster.
Again, going back to the webserver test, I'm sure all the other participants
were also trying their hardest to get impressive results and they failed.
Getting high performance out of a system is a bit more complex than you
suggest.
> Until it crashes. Which is
> what the argument really boils down to. When something which is part of
> the "kernel" crashes, do you want it to take down the whole machine or
> do you want it to be contained and replacable? A web server should run
> in user space. End of story. Debatably a file system and a network
> stack should run in user space.. if you can get sufficient performance.
If you want to trade off performance for the ability to recover from
bugs then you can run "user mode linux" and you have got the whole kernel
running in user space. Mind you, if your UML kernel is crashing regularly
then you are going to have to fix the bug sooner or later, just restarting
the job whenever it crashes is a bit crappy.
If you do not want to go the whole hog and run a fully isolated virtual
machine then you MIGHT be able to recover SOME of the time but think about
a situation where you have swap-to-disk implemented as a user space task
and it crashes. Can you recover the situation? All memory on the entire
system is now in an untrustworthy state so you must find a way of cleanly
restarting every task -- most people call this a reboot.
Same problem if you have a filesystem task in user space and it crashes --
what state did it leave the drive in? Restarting the task might quite
likely create further corruption. Again, if you have bugs at the filesystem
level then there really is no other answer than finding the bugs and fixing
them. Restarting the task won't actually solve anything. Being able to
make an attempt at recovery is a bogus sense of security.
I might also point out that some hardware devices can have nasty effects
on the system when used wrongly (e.g. graphics cards with DMA) so restarting
the task isn't going to help you if your PCI bus is locked solid by a
bad graphics operation. A microkernel, by its very nature, can't be smart
enough to protect you from these things and as far as I know there is
no architecture where hardware devices can be guaranteed free of side
effects.
> For a desktop operating system (which, remember, is what we were talking
> about) today's hardware is so much overkill that you could run different
> parts of the kernel on different parts of a local network and still get
> adequate performance.
In which case, why the earlier comment about the importance of real
time scheduling? I completely agree that a typical 2GHz Celeron can execute
any desktop task (except starting Open Office) in shorter time than I
can react to the results. I don't understand why scheduling is such an
important issue when the system is almost completely unloaded almost all
the time.
The only things that I have noticed killing destop performance are:
* Swapping. If you are running big-memory jobs and you don't have enough
memory then linux will swap out anything it likes including chunks of
your desktop code. This is not a scheduling issue.
* Choking the disk bandwidth with a large backup operation or file
transfer and trying to open desktop tasks at the same time. Linux has
no priority system for jobs waiting on I/O bandwidth (and such a system
is hard to implement because of the many layers of abstraction)
* Intensive graphics that are beyond what your system can actually handle
(in which case you can't win, get a better system)
I would be curious to know exactly what "real time" requirements there
are on desktop systems in terms of something that the user can detect.
For most operations, 1/4 of a second would be the smallest time interval
that a human can recognise so frankly I have trouble believing that some
millisecond difference in interrupt latency can be recognised at the
user interface level.
> So why are we still running it in ring-0?
> Because that's the system we have today and it doesn't make sense to
> reinvent the wheel if it is working.
And because microkernel designs have been tried (e.g. MS-Windows NT)
and so far they have proven both slower and less stable.
> But it does make sense to keep
> working on it and slowly migrate things out of ring-0 and into their own
> process space so we can get rock solid stability and the flexibility
> needed to implement and debug new things more safely.
There's two issues here. Stability of a production system can only
be achieved by getting bugs out of the code. This holds for any architecture
because restarting critical tasks (like memory management and filesystems)
can never be trusted to have a reliable result.
For experimentation with development systems, yes it is nice to have
something you can crash and restart quickly. The answer is either a second
box (one that boots fast) or some sort of virtualisation. To some extent,
linux kernel modules already provide a handy tool for experimentation
but you still need a second box because you are still going to be rebooting
every so often. For debugging an actual real time problem that involves
hardware interaction you just have to do it on a real box and if it locks
up the bus you just have to reboot.
- Tel
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
