> On 17. May 2017, at 08:59, Paul Goyette <p...@whooppee.com> wrote: > > On Wed, 17 May 2017, J. Hannken-Illjes wrote: > >>>> Chances are very high that you are hitting the free page lock contention >>>> bug. >>> >>> Further observation: >>> >>> 1. A run of lockstat shows that there's lots of activity on >>> mntvnode_lock from vfs_insmntque >>> >>> 2. The problem can be triggered simply by running 'du -s' on a >>> file system with lots of files (for example, after having run >>> 'build.sh release' for ~40 different architectures, and having >>> kept ALL of the obj/*, dest/*, and release/* output files). >>> >>> 3. The ioflush thread _never_ finishes. Even 12 hours after the >>> trigger, and after an 8-hour sleep window doing nothing (other >>> than receiving a couple dozen Emails), the ioflush thread is >>> still using 5-10% of one CPU core/thread. >>> >>> 4. If I umount the trigger file system, ioflush time goes to near- >>> zero. I can remount without problem, however shortly after >>> re-running the 'du -s' command the problem returns. >>> >>> There was a comment on IRC that yamt@ had been working on a problem where >>> "ioflush wastes a lot of CPU time when there are lots of vnodes" seems to >>> describe this situation. Unfortunately, it seems that yamt never finished >>> working on the problem. :( >> >> Two questions: >> >> - What is the size of your vnode cache (sysctl kern.maxvnodes)? > > kern.maxvnodes = 6706326
What happens if you lower it to 1258268 for example? -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)