Re: serial8250_interrupt idea

["George Spelvin" <linux@horizon.com>]

"Tosoni" <jp.tosoni@acksys.fr> wrote:

> I am talking about serial ports sharing the same interrupt.
> Here are more details.
>
> Let's say that you have N ports sharing the same interrupt. When the data
> rate is very high, or the processor is slow, the following may happen
> depending on how you prioritize the ports:
>
> say that high-speed frames of 150 chars arrive on ports X and Y.
>
> 1/ enter ISR
> 2/ test port X => process reception of a char, put it ahead of list
> 3/ during processing of 2/ another char arrived on X ; goto 2
> 4/ during processing of loop 2/ and 3/ many chars arrived on port Y, some
> were lost
> 4/ process Y and other ports
> 5/ All N ports are now quiet; exit ISR
>
> Now you have lost data on port Y because you prioritized X over Y.
>
> Got it ?

I see how some port has to be checked first, so if others share the
same interrupt, they have to be checked second.  I don't see how this
means that "one of them gets served much more often than the others";
both get served equally often.

I also don't understand how the above can be a serious problem.
Although slow relative to CPU speeds, the I/O port accesses are extremely
fast relative to serial data transmission rates.  Even at 115,200 baud,
characters arrive every 86.8 us.  Once the interrupt handler is executing,
bytes are removed from the serial FIFO at around 1 per us.  So not even
a full character can arrive at port Y in the time it takes to completely
empty 64 bytes out of port X's FIFO.

In other words, your step 4/ cannot actually happen.  If one more
character is enough to cause port Y to overflow, it's perilously close
to overflowing without port X.