Date: Sun, 30 Nov 1997 15:52:01 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, jak@cetlink.net Cc: hackers@freebsd.org Subject: Re: 650 UART, SIO driver, 8259 PIC Message-ID: <199711300452.PAA29084@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>>BTW, I remember why an EOI is sent on return and not at the start >>for the non-auto-EOI case. > >That was my next question. :-) > >>It is to reduce interrupt latency. > >I guess that depends on how you measure latency. But it seems that >the requesting device must wait the same length of time to get service >either way, at least in the case where the ISR leaves CPU interrupts >disabled until exiting with IRET automatically reenables them. Not sending the EOI early always reduces latency by the time it takes to do 1-2 i/o's (depending on how many of AUTO_EOI_1 and AUTO_EOI_2 are configured). Sending the EOI later only adds (almost unavoidable) latency if there another interrupt has become pending, but this is unlikely. >Perhaps EOI at the start (like auto-EOI) would be useful if the ISR >reenabled CPU interrupts to allow other devices to pre-empt the >current ISR. It's necessary for other devices to preempt the current ISR, and always done for "slow" interrupts (actually, the interrupt system preempts the current ISR and then decides what to do based on its own table of priorities). Preemption is not supported or very useful for "fast" interrupts. 8250 interrupts for a single UART can be handled so fast (5-10 i/o's) that there is no point in preempting them. This is not quite true for 16550 interrupts for multiple UARTs on one irq, but the scheduling for allowing interrupts is difficult. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711300452.PAA29084>