Audio after heavy filesystem activity
dillon at apollo.backplane.com
Thu Dec 20 14:33:29 PST 2007
: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 /
: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
: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.
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 :-)
<dillon at backplane.com>
More information about the Kernel