Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!mauxci!eci386!jmm
From: jmm@eci386.uucp (John Macdonald)
Newsgroups: comp.sys.3b1
Subject: Re: more on the HFC saga
Message-ID: <1991May31.185952.4619@eci386.uucp>
Date: 31 May 91 18:59:52 GMT
References: <1991May23.003857.8878@blilly.UUCP> <1991May28.035153.544@highspl> <1991May29.225254.27852@blilly.UUCP>
Reply-To: jmm@eci386.UUCP (John Macdonald)
Distribution: na
Organization: Elegant Communications Inc.
Lines: 85

In article <1991May29.225254.27852@blilly.UUCP> bruce@balilly (Bruce Lilly) writes:
|In article <1991May28.035153.544@highspl> burris@highspl (David Burris) writes:
|>
|>I don't understand this and I invite you to enlighten me.
|>
|>If we assume a steady stream of data and understand that all the
|>interrupt routines must be "polled" for each interrupt, where is the
|>time savings?
|
|Assume drivers are polled in the order
|driver1->driver2->driver3->driver4. A finite amount of time is required
|for each driver to determine whether it is responsible for handling an
|interrupt (i.e. polling the hardware). If driver4 has the interrupt
|handler, the interrupt will not be serviced until after driver1, driver2,
|and driver3 have determined that there are no interrupts for them. On the
|other hand, if the order is driver4->driver3->driver2->driver1, then
|dirver4 can handle interrupts in a more timely manner.
|
|Note that if there are many interrupts from different devices at the same
|interrupt level, some of the earlier drivers in the chain may find that
|there are interrupts for them that require servicing, further delaying
|drivers that are later in the chain.

There are some significant choices to be made when the kernel is being
set up.  The routine used to process shared interrupts has to choose
the answer to a number of questions, in particular:

    (1) What order to poll the low level drivers?
	Usually they are polled in the same order every time (scan a
	list in order).  An alternative is to keep the list in a loop
	and have some algorithm choose where to start (usually this
	is either the device that last interupted or the device that
	has least recently been polled).

    (2) When to quit?
	This can have such possibilities as: quit after the first
	driver has processed an interrupt, quit after all drivers
	have been polled once, quit after all drivers have denied
	having an outstanding interrupt.

(DISCLAIMER: I don't know how these issues were resolved for the
3b1 - I've looked into them for other Unix kernels on similar
hardware.)

In David's original question, I think that the work "all" means that
he is talking only about cases in which "all" drivers get polled for
each interrupt (at least once).

Bruce's answer is right for those cases where the scanner quits
after the first driver admits that the interrupt was for it.

David is right that there is no difference in potential delay if all
devices are scanned for each interrupt.  The time between the point
when a device raises an interrupt and the time when the driver gets
invoked includes the time required to poll all drivers later in the
chain for a previous interrupt that is still being processed as well
as the time to process any outstanding interrupts that there may be
for drivers that are earlier on the chain.  There some bias based on
position, but it disappears as soon as there are burst of three or
more fast incoming interrupts for the same device (and if you get
two fast enough to lose a character then you are almost always in a
situation where there will be a third coming at about the same
speed).

The "right" answer to the kernel design choices listed above depends
upon a number of things
    - how much buffering do the hardware devices have
    - are all devices connected to the same interrupt level really
	of equal importance [this is often impossible to determine
	completely until you look at the final layout in the end
	customers site]
    - can any or all of the devices afford to miss an interrupt (a
	mouse port that occassionally loses an interrupt won't be
	noticed - so what if you sometimes have to move the mouse
	27 millimeters and sometimes only 23 mm - so it could be
	put at the low end of an unfair scanner quite well).
    - are there any special hardware requirements (like having a
	programmable interrupt controller that expects individual
	acknowledgements and then tries to raise another interrupt
	if there are additional devices ready)
-- 
Usenet is [like] the group of people who visit the  | John Macdonald
park on a Sunday afternoon. [...] luckily, most of  |   jmm@eci386
the people are staying on the paths and not pissing |
on the flowers - Gene Spafford