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/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:16 EST