Andi Kleen writes:
> On Mon, Jul 03, 2000 at 10:18:30PM -0600, Richard Gooch wrote:
> > Andrew Morton writes:
> > > Roger Larsson wrote:
> > > > Note: I have seen X causing 50 ms latencies...
> > > > [aux_write_dev+26/28]
> > >
> > > awwwww.. Yuk. What a piggy little function!
> >
> > Yuck! It's even disabling interrupts for that long.
>
> Does anybody know if it just stupid locking or if the hardware
> requires interrupts off ?
Someone who understands the PC KBD controller should answer that. It
looks like command/read/ack cycles should not be interspersed with
other KBD accesses. That would not be an unreasonable hardware
limitation.
So with all that locking, the ISR may have to wait a long time for the
lock to yield. Even if other interrupts are not blocked, this will
still delay BH/tasklet processing, not to mention scheduling
latencies.
Someone more familiar with the current IRQ subsystem could help here:
- what happens if the interrupt handler does nothing with the
keyboard: does the interrupt keep banging the CPU and hence the
handler keeps getting run
- can we block delivery of an interrupt, so that other interrupts and
process rescheduling continues as normal?
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:15 EST