Date: Mon, 16 Aug 2004 19:21:39 -0600 (MDT) From: Scott Long <scottl@freebsd.org> To: "David O'Brien" <obrien@freebsd.org> Cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/i386/include vmparam.h Message-ID: <20040816191337.B32601@pooker.samsco.org> In-Reply-To: <20040817011018.GA67171@dragon.nuxi.com> References: <200408160835.i7G8ZM6d068546@repoman.freebsd.org> <20040817011018.GA67171@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 16 Aug 2004, David O'Brien wrote: > On Mon, Aug 16, 2004 at 04:28:34PM -0700, Alfred Perlstein wrote: > > * David E. O'Brien <obrien@FreeBSD.org> [040816 01:35] wrote: > > > obrien 2004-08-16 08:35:22 UTC > > > > > > FreeBSD src repository > > > > > > Modified files: > > > sys/i386/include vmparam.h > > > Log: > > > Increase the scaling of VM_KMEM_SIZE_MAX. > > > > Is there any chance we can scale up the max sockets/maxfiles a bit? > > > > I've found that for simple benchmarks, doubling or quadrupling > > didn't see to cause any instability would make us look better out > > of the box. > > The increase of VM_KMEM_SIZE_MAX is prevent (help delay?) panics on 4GB > i386 systems. Do you have benchmark data suggesting what would be better > values for max sockets/maxfiles? > The whole point of dynamic limits was to help auto-tune the system using the assumption that someone who spends money on more RAM is likely to have a workload that is more server-oriented (and thus needs more sockets and/or vnodes). The limit that you committed was based on an off-handed comment that I made with the intention of getting the number to a value so low that it would be very safe. Why you are committing numbers without doing your own extensive benchmarking and testing is quite beyond me. The reason that this wasn't done yet by someone else is not because everyone is lazy, it's because it's a very hard and time-consuming problem to solve. Stealing numbers out of thin air is easy but not really conducive to having a well-performing system. I thought that you would understand and appreciate this already. I'm also unclear on why you are raising VM_KMEM_SIZE_MAX but arguing with Alfred over raising kern.maxvnodes. They have a close relationship to each other, and I don't see why you are resistant to recognise that. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040816191337.B32601>