🚀 go-pugleaf

In article <tonyn-0109950144230001@tonyn.tiac.net>,
Tony Nelson <tonyn@tiac.net> wrote:
>I see some discussion here about "negligable preemtion / interrupt overhead".
>
>On any CPU, interrupt processing requires a context switch (also required
>for preemption and system services).  In the old days, this required
>simply the amount of time the CPU required to start the interrupt (and
>finish it later) plus the instructions in the interrupt handler.
>
>Nowadays the penalty for an interrupt is much greater, because of
>processor caches (or rather, fast processors but memory at the same speed
>as before).  The context switch now requires flushing the cache, so the
>processor will run slowly for a while as instructions are fetched from
>"real memory".  Not only will this slow down interrupt processing
>(relative to the estimate from the number of instructions involved), it is
>unpredictable.  I estimate that processors are spending the same amount of
>real time servicing interrupts as the did years ago, but I may be wrong --
>it may take much longer now, due to cache flush and reload.

You are wrong. In implementing a real-time system, most architectures
give you a range of choices about how to handle interrupts. You don't have
to do a full switch of virtual address spaces in your real-time system.
This is rarely a requirement. Thus your argument about flushing caches
applies to non-real-time systems where reponse times are not critical.

Some processors (e.g. MIPS) let the software implement a handler and
replacement algorithm for TLB misses, allowing the system to be further
tuned for real-time performance. For instance, your TLB replacement
algorithm can ensure that the most critical process has its thread code
locked into the virtual address translation cache, so that when it's
invoked by an interrupt, less data has to be reloaded.

>Deterministic real-time processing is difficult to do with interrupts. 
>You really can't tell when all the interrupts will stack up at the same
>time, causing the lowest priority interrupt to wait a long time.  Coupled
>with the overhead of context switching, this makes interrupt-driven
>programming impractical for device controllers (such as, say, a car or a
>wheelchair).  Polling with a heartbeat timer is used instead.  The most

Polling? You raelly can't tell when all devices will poll positive
at the same time, causing the lowest priority device to wait a long time...

BTW, how is a wheelchair a real-time system requiring microsecond, or even
millisecond response times? Maybe that's why you can use polling.

>time-critical tasks are polled oftenest.  Processing of different tasks is
>distributed in time by spreading out the polling.  Such systems can more
>easily be proved to work, which is comforting for the person in the
>wheelchair who is crossing a busy street.

"	Your honor, had my client's ACME wheelchair responded twenty
	milliseconds sooner to his pushing the lever forward...	"

Haha.

-- 
Finger c2a192@keats.ugrad.cs.ubc.ca for PGP public key. Or contact
one of the public key servers -- the key id is 0xD3C7995D.
Microsoft users: crash test dummies?