Subject: Re: observations on a large-memory system.
To: None <tls@rek.tjls.com>
From: Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us>
List: tech-kern
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
> 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