> Actually, I think there's another issue here.  Unless I miscount, struct
> vnode is about 100 bytes on x86; on LP64 platforms it's significantly
> larger since it's got lots of longs and pointers in it.

For what it's worth, vmstat -m shows the allocation size for each
pool.  You're off by a factor of two or so..  216 bytes on ILP32, 344
bytes on LP64.  And then there's the filesystem-specific vnode data
(in ffsinopl) and name cache info (in ncachepl).

> About a year ago, we discovered a serious performance problem caused by
> rsync on ftp.netbsd.org: rsync thrashes the namei cache by stating every
> vnode in the tree to by rsynced, which on nbftp meant somewhere over 100,000
> vnodes.  

More like two years ago, but who's counting..

> We attempted to increase NVNODE to address this issue and discovered
> that the amount of wired physical memory the kernel required to
> increase it sufficiently gave the pmap fits.
> 
> In our 200,000 vnode case we're discussing, we're talking about wiring down
> 20MB in the kernel for vnodes.  Is this less problematic now than it was
> then?

On i386, we've moved the kernel lower in memory so that i386 now has
1G kva space instead of 256MB.

					- Bill