Excessive delays due to syncer kthread

[Peter Jeremy]

On Sat, 2005-Feb-26 11:24:26 +0000, Robert Watson wrote:
>I don't have too much insight into the syncer (I've CC'd phk to victimize
>him with more e-mail as this is an area he takes great interested in).  A
>couple of questions: 
>
>(1) Have you tried turning on options PREEMPTION? 

I haven't yet.  I will look at this but some of the mailing list comments
made me think it wasn't totally reliable yet.

>(2) Does the driver code run with Giant at all? 

Yes.  It's marked INTR_MPSAFE and never grabs Giant.  The only locking
it needs is PROC_LOCK (and that's only for psignal(9)).

>(3) Are you relying on callouts or taskqueues at all for processing? 

No.

>running though.  So using preemption and Giant-free code, we should be
>able to get your driver code in kernel to run on short deadline, but
>getting the syncer to behave better will be necessary to get the user code
>running on short deadline.

The userland code is less of a problem.  The hardware can fit 3-6
frames (depending on depth) into a shared ring buffer - which gives me
60-120msec for the user code to wake up (100msec at the depth I will
normally use).  The problem is that the hardware can't autonomously
move between entries in the ring buffer so the interrupt handler needs
to re-write some device registers during the vertical blanking period
(~1.6msec).

Thanks for your input.
-- 
Peter Jeremy