Messages in this thread | | | Date | Wed, 5 Jul 2000 03:29:28 +0200 | From | "Andi Kleen" <> | Subject | Re: PS/2 mouse latency was Re: [linux-audio-dev] Re: [DATAPOINT] kernels and latencies |
| |
On Tue, Jul 04, 2000 at 12:04:59PM -0600, Richard Gooch wrote: > 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.
It would be possible to use a work queue similar to the socket lock: You lock against interrupts with a counter and when it is >0 they queue items (in this case function pointer + data) into a special queue. The queue is processed after unlock with the functions called in turn. A cheap variant for infrequent accesses of this is to start a 1 jiffie timer. To serialize user context you use a semaphore or the BKL. Unlike networking there are no ready allocated data structures yet so it would require an additional kmalloc/kfree (probably better spent time than spinning)
-Andi
- 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/
| |