[lkml]   [2000]   [Jul]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:57    [W:0.080 / U:0.376 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site