Date: Fri, 14 Nov 1997 14:10:33 GMT From: mouth@ibm.net (John Kelly) To: Bruce Evans <bde@zeta.org.au> Cc: bde@zeta.org.au, hackers@FreeBSD.ORG Subject: Re: Status of 650 UART support Message-ID: <346c51c4.1329130@smtp-gw01.ny.us.ibm.net> In-Reply-To: <199711140928.UAA25820@godzilla.zeta.org.au> References: <199711140928.UAA25820@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 14 Nov 1997 20:28:05 +1100, Bruce Evans <bde@zeta.org.au> wrote: >>In the case of a multiport serial adapter, each port could have a flag >>in sio.c which tells whether it's working in polled mode or interrupt >>mode. Whenever you poll the ports which are streaming data in, you >>would only have to check the ones which have their polling flag on, >>because any of the other ports not being polled would still get your >>attention by means of an interrupt. > >I don't see how to make this work with edge-triggered interrupts. Edge triggered interrupts are not a factor. >E.g., suppose no ports are active and we get an interrupt. Then all >ports must be in interrupt mode and we have to check them all and turn >off the interrupt enables for those that are generating an interrupt. >Then we return from the interrupt and switch to polled mode. This costs >more than the current checking. We still have to check all ports No. >average of 1.5 times around the loop for an average active port found >half way round the loop). There are extra costs for context switching >and toggling the interrupt enables. I also want to pursue some other points in your reply, but I want to clear up this point before proceeding. 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. :-) 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*. Remember, it won't matter whether you *always* service the inbound data fast enough, or whether your normal scheduled interrupt is interrupted to run some other task, because the 650 auto RTS will do inbound flow control all by itself. If you see that the inbound FIFO is always full when you start to empty it, you know you are not servicing the data stream fast enough. You can then adjust the scheduling priority and/or time as needed to keep up with the inbound data. That is how you will avoid loss of throughput and efficiency. If the data stream throughput falls below the "warp" threshold, you drop the port back to impulse power -- er, interrupt mode. Each port would be switched individually, according to its data stream throughput (you would have to track that for each port), no matter whether you have an interrupt sharing multiport card, plain old serial cards, or some mix of the two (but only for ports with 650 UARTs). All this would require looking at the kernel scheduling code. That's why I earlier suggested it might take someone foolhardy to attempt it. But for now at least, I only want to know whether the concept is good, without concern for how much work it might require. John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?346c51c4.1329130>