Andi Kleen writes:
> 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.
OK, but there's still one point that hasn't been answered: what
happens if you don't clear the interrupt condition? Will the ISR keep
getting called, or is it called only once?
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
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