DragonFly users List (threaded) for 2006-01
Re: copying pkgsrc tree around jails on beefy machine - fast on 2nd iteration, a bit slower than first on 3rd iteration
On 1/5/06, Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx> wrote:
> :If the machine has 3-4GB of memory why shouldn't the vnode and buffer
> :cache do some better auto tunning. If the kernel has a VM system
> :shouldn't the kernel be aware of how much memory is in use for the
> :entire system and make all of the system caches larger ?
> The kernel is fairly conservative with regards to the number of vnodes
> it allows to be cached because the memory required to hold the vnodes
> and related VM structures can exceed the kernel's own fairly limited
> address space. When doing copy operations on large numbers of small
> files, the vnode limit will often be hit before the memory limit.
> (When copying larger files the memory limit is hit before the vnode
> You can adjust the number of vnodes the kernel caches with the
> 'kern.maxvnodes' sysctl. So, e.g. /usr/pkgsrc has around 105000
> files so if you want to support caching of a cpdup you would need
> to be able to cache ~210000 vnodes. If you make the number too
> big, however, you run a serious risk of running the kernel out of
> Unless you actually *NEED* to cache whole file structures for
> performance reasons in a production environment, I would *NOT*
> recommend that the system default be changed.
Shouldn't the vnode recycler keep the number of vnodes down so that
you don't exhaust the KVM space ?
I did a quick little test on my machine and it looks like you'll hit
this condition in vfs_mount.c if maxvnodes is set too high.
635 if (vnlru_nowhere % 100 == 0)
636 printf("vnlru_proc: vnode
recycler stopped working!\n");