From owner-freebsd-hackers  Fri Nov 14 05:58:28 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id FAA29605
          for hackers-outgoing; Fri, 14 Nov 1997 05:58:28 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA29591
          for <hackers@freebsd.org>; Fri, 14 Nov 1997 05:58:24 -0800 (PST)
          (envelope-from bde@zeta.org.au)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id AAA01430; Sat, 15 Nov 1997 00:53:34 +1100
Date: Sat, 15 Nov 1997 00:53:34 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199711141353.AAA01430@godzilla.zeta.org.au>
To: bde@zeta.org.au, mouth@ibm.net
Subject: Re: Status of 650 UART support
Cc: hackers@freebsd.org
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>>I don't see how to make this work with edge-triggered interrupts.
>
>Edge triggered interrupts are not a factor.

Yes they are.

>A port would not be switched to polled mode until its inbound data
>throughput crosses some defined threshold for some defined period of
>time -- think of it like a starship making the jump from impulse power
>to warp drive -- you don't make the switch until you near light speed.
>:-)

This would put ports in polled mode even less than I thought you meant.
It would be even more common for all ports to have their interrupts
enabled, so the interrupt handler would have go round the loop checking
them all an average of almost 1.5 times.  (The current version goes
round an average of 0.5 times too many.)

>As long as data streams in at high speed, you leave the port in polled
>mode, grabbing its inbound data, not with a fast interrupt, but with a
>normal scheduled interrupt with other interrupts *enabled*.

This won't work, since interrupts need to be reenabled on the polled
ports as soon as everything in them is polled.  Otherwise you may not
get around to looking at them soon enough.  The next clock interrupt
is an average of 5 msec away, and it's silly to delay processing of
warp speed ports _more_ than ordinary ports.

The reverse would work better: keep interrupts disabled on ports that
were inactive for the last few msec and poll these ports every 10 msec.
Otherwise handle them the same as now except for skipping the polled
ports in the loop in siointr().

>All this would require looking at the kernel scheduling code.  That's

Actually not.  Low priority polling is already supported (configure
without a vector).  There just needs some code to move ports on and
off the polled list.  The loop should skip polled ports now but it
doesn't bother.  It doesn't even bother ports skipping closed ports.
This is currently reasonable since polled ports are very uncommon
and closed ports are probably uncommon (half-open ports waiting for
carrier are probably common).

Bruce