Messages in this thread | | | Date | Wed, 5 Jul 2000 10:55:15 +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 08:33:27PM -0600, Richard Gooch wrote: > [Cc list trimmed] > Andi Kleen writes: > > On Tue, Jul 04, 2000 at 12:04:59PM -0600, Richard Gooch wrote: > > > 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. > > I don't understand how this would work. Taking a lock doesn't prevent > interrupts. And once you start playing with the KBD controller, how > can the ISR do anything but wait until you've finished? The problem is > the time spent playing with the KBD controller (most of it spent > waiting for it to become ready).
My understanding is that it is no problem to take an interrupt, you just cannot act on it until a possible aux_write has been finished. The backlog scheme just serializes.
-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/
| |