Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wasatch!cs.utexas.edu!uunet!lts!amanda@lts.UUCP
From: amanda@lts.UUCP
Newsgroups: comp.protocols.tcp-ip
Subject: interrupt-driven vs. polled I/O performance
Summary: yes and no :-)
Message-ID: <14-Apr-89.114221@192.41.214.2>
Date: 14 Apr 89 15:37:09 GMT
Sender: news@lts.UUCP
Organization: InterCon Systems Corporation, Reston, VA
Lines: 70
X-Posting-Front-End: Stop by Booth #329, MacWorld/Expo DC...

Dave Crocker argues with Henry Spencer about interrupts:
>[...]
>Interrupts kill.
>
>The raw machine processing time -- i.e., hardware instruction cost -- for
>interrupts is quite significant.  As with most features in this world,
>interrupts are excellent for their intended purpose and questionable for
>other situations.
>
>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.

Well, I wouldn't say it's quite so clear cut as all of that.  Granted,
the absolute best raw data rate through a given interface (of whatever
sort) can be achieved by polling, principally because there is then no
need to save and restore any state--the processor is only doing I/O.
This is one of the reasons that separate I/O processors are such a big
performance win: I/O state gets encapsulated in hardware rather than
software.

What I think Henry was getting at, though, is that given a processor
which is doing both I/O and other tasks (or, for that matter, which is
being subjected to an unpredictable I/O load), careful attention to
how interruptsa are handled can make an incredible difference in
real-time response and overall performance, for exactly some of the
same reasons that polling wins.  

The general idea is that you do as little processing as possible one
character at a time.  For example, a serial input interrupt service
routine should stuff the incoming character in a buffer *and that's it*.
This only takes a few microseconds on the kinds of processors being used
in most workstations and desktop computers.  In other words, interrupts
are used to approximate the behavior of a hardware FIFO.  No context
switches or wakeups, just "push a register or two, grab the input,
stuff it into a buffer, update the buffer head, and return."
This buffer is then polled by the upper-level code, which (especially
under high load) then has a chance of grabbing a whole block of data at
once, which it can then rip through all at once without having to switch
state.  Sound familiar :-)?  When I first saw the code to the UNIX tty
handler, my first question was "why are they doing all of this at
interrupt time?"  So far, I've never seen an answer to that besides
"historical reasons."

Now, if you do have the luxury of a dedicated I/O processor, polling and
hardware FIFOs are the way to go.  For an Ethernet terminal sever, for
example, a LANCE (or other chip that buffer bunches of back-to-back
packets all by its little lonesome self) plus FIFOs between the serial
chips and the processor will give you some impressive throughput even
with a relatively wimpy 6MHz 80186...

>Many, occasional sources of activity warrant interrupts.
>A few, active sources warrant polling.
>
>Dave

How 'bout we add "A non-I/O-dedicated processor warrants interrupts?"

I agree with you in general, I just don't see how it's too relevant to
the discussion, which (to me anyway) seemed to be "how can we keep
workstations from croaking under heavy input traffic?"

Of course, this approach is also useful in upper-level processing as well.
For example, it doesn't matter how well your network I/O code is if your
RPC input queue is only 8 items long, and 50 NFS clients try to mount one
of your filesystems...

Amanda Walker
InterCon Systems Corporation
amanda@lts.UUCP