Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!mcvax!ukc!dcl-cs!aber-cs!pcg
From: pcg@aber-cs.UUCP (Piercarlo Grandi)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Interrupts & Polling [was: Re: Super Cheap IP router (< $1000)]
Summary: Well, once you get an interrupt, always look around for more work...
Message-ID: <820@aber-cs.UUCP>
Date: 14 Apr 89 21:06:21 GMT
Reply-To: pcg@cs.aber.ac.uk (Piercarlo Grandi)
Distribution: eunet,world
Organization: Dept of CS, UCW Aberystwyth
	(Disclaimer: my statements are purely personal)
Lines: 41

In article <25223@amdcad.AMD.COM> rpw3@amdcad.UUCP (Rob Warnock) writes:
    dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker) writes:
    +---------------
    | Interrupts kill...
    | An interrupt is very useful when you don't expect much activity and don't
    | want the overhead of polling.  On the other hand, if you DO expect heavy
    | activity, polling is quite nice...
    | Many, occasional sources of activity warrant interrupts.
    | A few, active sources warrant polling.
    +---------------
    
    Which is why the two-level interrupt service structure I wrote a
    "tutorial" about in comp.arch (circa 3/20/89?) does exactly this,
    although that was not one of the points I stressed in that article.
    
    In the absence of interrupt activity, you are "interrupt driven".
    But once you get an interrupt, additional interrupts are queued on
    a lightweight task queue, and [this is the part I left unstressed]
    every second-level interrupt routine checks for more work of its
    own type before exiting, and if there is any, requeues itself on
    the tail of the task queue.

While I agree that the technique is useful, it requires implementing
a lightweight process system in your kernel, which may be major
surgery. In a sense, you are using any interrupt as though it were
the clock interrupt to start polling.

The simple version, used e.g. in many UNIX kernels, is to have any
and every interrupt processing procedure always check at the end for
further pending interrupts for ITSELF, and then go into a loop. Even a
little busy waiting, if it is known that there will be a next interrupt
shortly, may be worthwhile, e.g. when reading packets/bursts from
line on which you are running a protocol.

I do not like much the idea of having an interrupt routine at the end
fire up polling in other drivers. (If I understood correctly what you
are thinking about).
-- 
Piercarlo "Peter" Grandi            |  ARPA: pcg%cs.aber.ac.uk@nss.cs.ucl.ac.uk
Dept of CS, UCW Aberystwyth         |  UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK  |  INET: pcg@cs.aber.ac.uk