copying pkgsrc tree around jails on beefy machine - fast on 2nd iteration, a bit slower than first on 3rd iteration

[Terry Tree]

On 1/2/06, Matthew Dillon <dillon at xxxxxxxxxxxxxxxxxxxx> wrote:
>
> :Hello!
> :
> :       While testing 1.4rc with jails - actually preparing for jails I noticed this:
> :
> :dk# cd /usr/
> :dk# time cp -pr pkgsrc /jails/pgsql81/usr
> :0.296u 9.586s 2:09.93 7.5%      59+440k 26099+1175io 90342pf+0w
> :dk# time cp -pr pkgsrc /net/jails/oglasi/usr
> :0.429u 8.692s 0:48.14 18.9%     61+447k 1816+1175io 7084pf+0w
> :dk# time cp -pr pkgsrc /jails/mysql/usr
> :0.445u 14.146s 2:12.14 11.0%    56+415k 1889+1176io 80390pf+0w
> :dk# du -sk /usr/pkgsrc
> :357080  /usr/pkgsrc
> :
> :
> :Basically I was copying 357MB pkgsrc dir from master to jails in a row. I manually re-edited destination each time. All
> :in a row, but you can see that 3rd copy did not benefit at all from first two copies. Since this machine is waiting for
> :those jails to actually do something I was under impression that 4GB RAM that this machine sees will benefit a lot in
> :copying - something like in 2nd case, but I was surprised that caching did not help at all in third case even though
> :things were being copied in a row - usually few seconds apart. Isn't DFly one of so called lazy-swappers where things do
> :not go out of memory if memory needs for programs are low?
> :
> :Toma¾
>
>     This is likely just the vnode cache getting blown out.  /usr/pkgsrc has
>     over 100,000 files and directories in it.
>
>                                         -Matt
>                                         Matthew Dillon
>                                         <dillon at xxxxxxxxxxxxx>
>

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 ?