From owner-cvs-src@FreeBSD.ORG Tue Aug 17 01:21:21 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5AF716A4CE; Tue, 17 Aug 2004 01:21:21 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E61E43D39; Tue, 17 Aug 2004 01:21:21 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from pooker.samsco.org (scottl@localhost [127.0.0.1]) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i7H1Le1K056837; Mon, 16 Aug 2004 19:21:40 -0600 (MDT) (envelope-from scottl@freebsd.org) Received: from localhost (scottl@localhost)i7H1LdBw056834; Mon, 16 Aug 2004 19:21:39 -0600 (MDT) (envelope-from scottl@freebsd.org) X-Authentication-Warning: pooker.samsco.org: scottl owned process doing -bs Date: Mon, 16 Aug 2004 19:21:39 -0600 (MDT) From: Scott Long Sender: scottl@pooker.samsco.org To: "David O'Brien" In-Reply-To: <20040817011018.GA67171@dragon.nuxi.com> Message-ID: <20040816191337.B32601@pooker.samsco.org> References: <200408160835.i7G8ZM6d068546@repoman.freebsd.org> <20040817011018.GA67171@dragon.nuxi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: cvs-src@freebsd.org cc: Alfred Perlstein cc: src-committers@freebsd.org cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/i386/include vmparam.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2004 01:21:21 -0000 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 [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