|Matthew Dillon||Jun 23, 2000 11:36 am|
|David Greenman||Jun 24, 2000 9:10 pm|
|Matthew Dillon||Jun 25, 2000 10:24 am|
|Jake Burkholder||Jun 25, 2000 11:19 am|
|Chuck Paterson||Jun 26, 2000 9:50 am|
|Matthew Dillon||Jun 27, 2000 10:41 am|
|Chuck Paterson||Jun 27, 2000 11:19 am|
|Kevin Van Maren||Jun 29, 2000 1:52 pm|
|Greg Lehey||Jul 2, 2000 6:51 pm|
|Jason Evans||Jul 3, 2000 8:41 am|
|Jake Burkholder||Jul 3, 2000 1:14 pm|
|Jake Burkholder||Jul 5, 2000 2:23 am|
|Matthew Dillon||Jul 5, 2000 9:43 am|
|Chuck Paterson||Jul 5, 2000 9:52 am|
|Chuck Paterson||Jul 5, 2000 9:57 am|
|Luoqi Chen||Jul 5, 2000 10:29 am|
|Matthew Dillon||Jul 5, 2000 11:28 am|
|Greg Lehey||Jul 5, 2000 4:20 pm|
|Doug Rabson||Jul 6, 2000 1:26 am|
|Matthew Dillon||Jul 6, 2000 10:43 am|
|Greg Lehey||Jul 22, 2000 2:26 am|
|Matthew Dillon||Jul 22, 2000 9:20 am|
|Chuck Paterson||Jul 22, 2000 9:57 am|
|Bruce Evans||Jul 22, 2000 10:36 am|
|Greg Lehey||Jul 23, 2000 8:14 pm|
|Bruce Evans||Jul 24, 2000 1:08 am|
|Chuck Paterson||Jul 24, 2000 6:43 am|
|Matthew Dillon||Jul 24, 2000 9:16 am|
|Subject:||Re: ipending (was: SMP progress (was: Stepping on Toes))|
|From:||Bruce Evans (bd...@zeta.org.au)|
|Date:||Jul 22, 2000 10:36:17 am|
On Sat, 22 Jul 2000, Matthew Dillon wrote:
:In a similar way, I'm removing interrupt mask copies in memory. We :still mask interrupts which aren't in use, but no others. If anybody :has any reason not to want to do this, we should talk about it. : :Greg
That would be wrong. The interrupt masks are kept in memory because it is much faster to access them there. Several hundred times faster than PIC accesses on current machines. When I implemented this on 1992's machines, the memory copies were less than ten times faster. The APIC case is not as bad. I don't know the details of it.
I think you still have to mask level interrupts, otherwise you won't be able to sti. Some subsystems may generate a phenominal number of interrupts while the interrupt routine is running -- for example, ^^^ another the serial ports. I think the masking was put in there as an
E.g., one serial port interrupting every 87 usec gives about 50 interrupts while the keyboard interrupt handler is busy-waiting to program the keyboard LEDs.
optmiization not only for that, but also so the interrupt could be EOI'd early so as to allow a new interrupt to become pending while the interrupt routine was running (thus closing a potential window of opportunity where an interrupt might otherwise be missed).
This only works right for interrupts other than the one being handled (we guarantee not to miss other interrupts provided they are live for at least the few usec needed for interrupt processing before the EOI). Masking the current interrupt prevents ipending getting set for it, and there is race to exit from the interrupt handler and clear the masks so that a new transient interrupt can be seen before it goes away. We certainly lose this race in some cases, e.g., when the exit is interrupted by another interrupt handler than takes too long. I suspect that most "stray" interrupts are caused by losing this race.
If you remove the masking you have to delay the EOI and that is probably a huge mistake because it may lead to lost interrupts. Another example: if a keyboard interrupt is lost you can lose the keyboard entierly. If
This doesn't seem to be a problem in practice. I think the keyboard controller times out and sends a new interrupt.
the EOI is delayed there is a much greater chance of losing the keyboard interrupt.
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message