At 2003-02-25 08:49 -0800, Faasse, P.R. wrote:
>A device driver will normally do little else than tell the device that it has 
>'seen' the interrupt, and leave all 'real' work to another mechanism (DPC on 
>WinNT, driver thread on Linux). This means that the real work will start only 
>after the complete poll list for all drivers that have registered for the interrupt 
>has been processed. The only difference i can see is the length of the poll list.
>With more interrupts, the poll list is shorter (assuming the devices are evenly 
>distributed over the interrupts..). Is that the mean reason, or did i miss something
>(again..)?

In the Unix that we used on our self-built 6809 Unix
system around 1985 I implemented a self-sorting poll
list of interrupt handlers.

Before I implemented it, the console (which traditionally
was tty0, which is the terminal of the system manager)
was the fastest but lower down the line the terminals
(tty1, tty2, tty3 ...) would
get slower and slower, because in those days every
character sent to the terminal required a CPU-interrupt.
That was very annoying, especially when using full-screen
editors.
After implementing the time sorted polling list, all the
terminals would be equally fast (but all a bit slower
than the console used to be). When we connected all the
terminals at 4800 baud instead of 9600 baud this worked
very well, because each terminal would be too slow to
stay on the top of the poll-queue and it was very unusual
that two or more people were refressing their screens
at the same time.

I probably didn't include the timer-interrupt in the poll
list, because it should have a higher priority, for example
because it keeps time and may be needed to resolve
deadlocks. Of course floppy-disk and harddisk interrupts
could be in the poll list, because they also have a very
peaky-behaviour. And it's probable that the person causing
the many interrupts with his terminal is likely to be
doing something on disk next and that will slow him down,
giving the others a chance to get their interrupts handled.

Of course one could think of much more elaborate schemes,
but all this has to be evaluated at every interrupt so
it must use a minumum of cycles. Just putting the last
handled interrupt source at the front of the linked list
involves changing only about three pointers.

Greetings,
Jaap

-- 
Author: Jaap van Ganswijk
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB CHIPDIR-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

Reply via email to