[lkml]   [2000]   [Jul]   [4]   [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 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
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)


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.056 / U:4.508 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site