Excessive delays due to syncer kthread

Robert Watson rwatson at FreeBSD.org
Sat Feb 26 11:26:15 GMT 2005


On Sat, 26 Feb 2005, Peter Jeremy wrote:

> I am trying to do some video capture and have been losing occasional
> fields.  After adding some debugging code to the kernel, I've found that
> the problem is excessive latency between the hardware interrupt and the
> driver interrupt - the hardware can handle about 1.5msec of latency. 
> Most of the time, the latency is less than 20µsec but but I'm seeing up
> to 8 msec occasionally.  In virtually all cases where there is a
> problem, curproc at the time of the hardware interrupt is syncer.  (I
> had one case where there was another process, but it had died by the
> time I went looking for it).  The interrupt is marked INTR_TYPE_AV so it
> shouldn't be being delayed by other threads.  (I can't easily make it
> INTR_FAST because it needs to call psignal(9)). 
> 
> The system is an Athlon XP-1800 with 512MB RAM and 2 ATA-100 disks
> running 5.3-RELEASE-p5.  It has a couple of NFS exports but doesn't
> import anything.  There's nothing much running apart from ffmpeg
> capturing the video and a process capturing my kernel debugging output. 
> Apart from 4 files being sequentially written as part of my capture and
> cron regularly waking up to go back to sleep, there shouldn't be any
> filesystem activity.  I tried copying a couple of large files and
> touching lots of files but that didn't cause any problems. 
> 
> Can anyone suggest why syncer would be occasionally running for up to 8
> msec at a time?  Overall, it's not clocking up a great deal of CPU time,
> it just seems to grab it in large chunks. 

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? 

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

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

With PREEMPTION enabled and all driver code running without Giant (and not
depending on threads that also acquire Giant), and all related workers
running with adequate priority, your driver threads should preempt the
syncer.  Your user process will have to wait for the syncer to finish
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.

Robert N M Watson




More information about the freebsd-stable mailing list