Audio after heavy filesystem activity

[Matthew Dillon]

:This is indeed the same problem as in FreeBSD - if number of vnodes grows 
:too large, sync will start to take too much time causing fatal schedule / 
:syscall latencies.
:
:It was confusing me for some time why it happens only on some of my 
:machines, but it's clear now. I did some small tests with my desktop with 
:2GB memory and Intel Core 2 Duo E6320 (1.86GHz):
:
:$ sysctl kern | grep vnode
:kern.maxvnodes: 136848
:kern.minvnodes: 34212
:
:There is the easy way to trigger the problem: "find / -type f >/dev/null".
:Audio glitches will appear if debug.numvnodes exceeds ~100000. Setting  
:kern.maxvnodes to something below 100000 (I'm using 68424 - default in 
:systems with 1GB memory) makes the problem to go away.
:
:At least I have a workaround now, but it's not real fix of course. There 
:is obvious performance problem that needs to be fixed.
:
:-- 
:Hasso

    Well, insofar as I know the vnode scan is not done in a critical
    section.  But if the sound device is using a helper thread the
    scheduling of that thread could be delayed due to the tight loop
    the vnode scan represents.  It could also be an issue with the
    scheduling of the interrupt thread itself... if the interrupt is
    unable to preempt the kernel it gets scheduled as a thread.

    There are several possible causes and several possible solutions.
    Ultimately running the sound device interrupt MPSAFE would allow it
    to preempt the kernel in nearly all situations.   Separating the
    mount point's vnode list into a clean list and a dirty list would
    also reduce the amount of scanning SYNC has to do by a lot.  Doing
    a staggered sync would also help.... right now its done on a mount
    by mount basis.

    I like the simplicity of your workaround :-)

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>