Re: CVS commit: syssrc/sys/miscfs/nullfs

[enami tsugutomo <enami%sm.sony.co.jp@localhost>]

Bill Studenmund <wrstuden%netbsd.org@localhost> writes:

> I agree that something other than 16 is probably good, but I don't think
> this is it. Do we have any performance data saying 16 isn't good enough?

When I first noticed this, I saw system sometimes eats 90% of time in
kernel mode and there was 10000 nodes on a same slot (when
desiredvnodes is 48000 and I was running cvs update on pkgsrc).

I did simple test again today.  With 16, system spends 2 or 3 times in
kernel mode.

16:
enami@annex-2f-floor-217% for i in 1 2 3; do CVS_RSH=ssh csh -c 'time cvs -q 
update -dP audio >/dev/null'; done
1.4u 5.8s 0:24.30 30.0% 0+0k 940+1112io 53pf+0w
1.5u 5.0s 0:41.55 15.7% 0+0k 484+1241io 0pf+0w
1.5u 5.6s 0:17.92 40.1% 0+0k 402+992io 0pf+0w
enami@annex-2f-floor-217% for i in 1 2 3; do CVS_RSH=ssh csh -c 'time cvs -q 
update -dP audio devel >/dev/null'; done
3.6u 18.3s 3:47.10 9.7% 0+0k 5927+5251io 0pf+0w
3.8u 20.5s 2:59.51 13.5% 0+0k 5774+5318io 0pf+0w
3.5u 25.5s 3:14.47 14.9% 0+0k 6050+5596io 0pf+1w
enami@annex-2f-floor-217% for i in 1 2 3; do CVS_RSH=ssh csh -c 'time cvs -q 
update -dP audio devel >/dev/null'; done
4.1u 28.0s 3:17.65 16.2% 0+0k 6231+5597io 1pf+1w
4.1u 28.1s 3:40.11 14.6% 0+0k 6181+5623io 0pf+1w
3.8u 28.5s 3:39.36 14.7% 0+0k 5924+5712io 0pf+1w
enami@annex-2f-floor-217% 


desiredvnodes:
enami@annex-2f-floor-217% for i in 1 2 3; do CVS_RSH=ssh csh -c 'time cvs -q 
update -dP audio >/dev/null'; done
1.6u 3.0s 0:19.72 23.9% 0+0k 987+1145io 54pf+0w
1.5u 2.8s 0:44.65 9.8% 0+0k 270+786io 1pf+1w
1.6u 2.7s 0:17.08 25.9% 0+0k 399+864io 0pf+0w
enami@annex-2f-floor-217% for i in 1 2 3; do CVS_RSH=ssh csh -c 'time cvs -q 
update -dP audio devel >/dev/null'; done
3.5u 8.3s 3:47.66 5.2% 0+0k 5933+5217io 0pf+0w
3.5u 7.8s 2:37.47 7.2% 0+0k 5203+4759io 0pf+0w
3.0u 8.4s 2:56.72 6.5% 0+0k 6226+5483io 0pf+1w
enami@annex-2f-floor-217% for i in 1 2 3; do CVS_RSH=ssh csh -c 'time cvs -q 
update -dP audio devel >/dev/null'; done
3.6u 7.8s 3:48.49 5.0% 0+0k 6409+5555io 0pf+1w
3.3u 8.1s 3:17.29 5.8% 0+0k 6419+5472io 0pf+1w
3.3u 8.2s 3:04.75 6.2% 0+0k 6243+5498io 0pf+1w

> First, since each layer vnode has a lower vnode, we will have at
> most half the system vnodes in the hash table (we are hashing the
> lower vnode).

Ya, after I commited that I once thought to change it to /2 or /4, but
recently I tend to think how worth the (current implementation of)
layer node cache is (while there is some other side effects like
PR#15555).

enami.