Date: Mon, 2 Aug 2004 20:36:28 -0500 From: Alan Cox <alc@cs.rice.edu> To: Scott Long <scottl@freebsd.org> Cc: "David E. O'Brien" <obrien@freebsd.org> Subject: Re: cvs commit: src/sys/kern vfs_subr.c Message-ID: <20040803013628.GU18577@cs.rice.edu> In-Reply-To: <410EE627.8090105@freebsd.org> References: <200408022152.i72Lqhig042925@repoman.freebsd.org> <410EE627.8090105@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Aug 02, 2004 at 07:11:03PM -0600, Scott Long wrote: > David E. O'Brien wrote: > > >obrien 2004-08-02 21:52:43 UTC > > > > FreeBSD src repository > > > > Modified files: > > sys/kern vfs_subr.c > > Log: > > Put a cap on the auto-tuning of kern.maxvnodes. > > > > Cap value chosen by: scottl > > > > Revision Changes Path > > 1.518 +8 -0 src/sys/kern/vfs_subr.c > > Well, the number that I gave was really only a suggestion and is > far too low to be useful on in a production environment like > squid or a mail/imap server. What we should really be doing is > scaling based on the size of the kmem_map. We should also be > scaling kmem_map based on the size of physical RAM and not capping > it to such relatively low values like we do right now. I'm also > quite afraid of what might happen to something like squid that > will be exerting both vnode and mbug pressure at the same time. > It does scale with the amount of physical memory. There is, however, an architecture-specific cap to account for the KVA size. This cap is now too low, particularly, on i386. In short, VM_KMEM_SIZE_MAX needs to increase on i386. I just don't know how large of an increase is safe. Do you have access to an i386 with 4+ GB of RAM? Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040803013628.GU18577>