Subject: Re: observations on a large-memory system.
To: None <email@example.com>
From: Bill Sommerfeld <firstname.lastname@example.org>
Date: 06/19/2001 20:20:43
> 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
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
On i386, we've moved the kernel lower in memory so that i386 now has
1G kva space instead of 256MB.