From owner-cvs-all@FreeBSD.ORG Tue Aug 17 01:10:20 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1AE5416A4CE; Tue, 17 Aug 2004 01:10:20 +0000 (GMT) Received: from TRANG.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE93A43D31; Tue, 17 Aug 2004 01:10:19 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by TRANG.nuxi.com (8.13.1/8.12.11) with ESMTP id i7H1AIM4077559; Mon, 16 Aug 2004 18:10:18 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.13.1/8.13.1/Submit) id i7H1AIeq077558; Mon, 16 Aug 2004 18:10:18 -0700 (PDT) (envelope-from obrien) Date: Mon, 16 Aug 2004 18:10:18 -0700 From: "David O'Brien" To: Alfred Perlstein Message-ID: <20040817011018.GA67171@dragon.nuxi.com> References: <200408160835.i7G8ZM6d068546@repoman.freebsd.org> <20040816232834.GF57908@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040816232834.GF57908@elvis.mu.org> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: cvs-src@freebsd.org cc: src-committers@freebsd.org cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/i386/include vmparam.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2004 01:10:20 -0000 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? -- -- David (obrien@FreeBSD.org)