🚀 go-pugleaf

In article <979@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
>I seem to remember reading that Unix context switch time is 10% the actual
>switch, 90% the cost of calling the scheduler to choose the next running
>process.
>...
>    Last week I saw an ad for a real time version of Unix with a guaranteed
>    response time (switch to kernel to high priority process) of 5
>    milliseconds.
>A note here: I saw similar ads in the past. 5 ms means 200hz. Booooooo!

This discussion is comparing apples and oranges.

The Unix context switch is, semantically, the time to put the running
process to sleep, choose a new one, and make him running. Further,
the quoted numbers are usually "typical" or "average".

The 5 ms. number (we all know whose) is the time from an interrupt
request strobe, to the execution of a core-locked user-level routine.
More importantly, it is a guaranteed worst-case number.  The system
in question will do more than 200 of these per second - again,
guaranteed worst case - under some load assumptions, of course.

I can't give a complete breakdown, because I lent the material to the
friendly black hole next door. However, those milliseconds are
certainly not ticking away while the machine wrestles with its
humongous register set. It's a 68020, people. The worst case involves
things like interrupt during an interrupt. It involves things like
the running user process being in the middle of a system call which
locks kernel resources and then discovers a worst-case implication
(such as setting up a disk cache flush?). It involves cache faults
and TLB faults and ALL that stuff. Hey, it's real time, and real
world, and "big" system - multiple interrupt sources, and file system
activity.

I will agree that five milliseconds lacks somewhat of Buddha Nature.
A better RT kernel would be more preemptable. But would having four
times the registers have made much difference? No.
-- 
Don		D.C.Lindsay 	Carnegie Mellon School of Computer Science
				Word for the day: Semantodontics.

--