From owner-cvs-src@FreeBSD.ORG Tue Aug 17 01:42:03 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 2F0A916A4CE; Tue, 17 Aug 2004 01:42:03 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id A86AD43D41; Tue, 17 Aug 2004 01:42:02 +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 i7H1gL8E056926; Mon, 16 Aug 2004 19:42:21 -0600 (MDT) (envelope-from scottl@freebsd.org) Received: from localhost (scottl@localhost)i7H1gLBg056923; Mon, 16 Aug 2004 19:42:21 -0600 (MDT) (envelope-from scottl@freebsd.org) X-Authentication-Warning: pooker.samsco.org: scottl owned process doing -bs Date: Mon, 16 Aug 2004 19:42:21 -0600 (MDT) From: Scott Long Sender: scottl@pooker.samsco.org To: "David O'Brien" In-Reply-To: <20040817013700.GB88749@dragon.nuxi.com> Message-ID: <20040816193941.P32601@pooker.samsco.org> References: <200408160835.i7G8ZM6d068546@repoman.freebsd.org> <20040817011018.GA67171@dragon.nuxi.com> <20040817013700.GB88749@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:42:03 -0000 On Mon, 16 Aug 2004, David O'Brien wrote: > On Mon, Aug 16, 2004 at 07:21:39PM -0600, Scott Long wrote: > > 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 > > The VM_KMEM_SIZE_MAX change came straight from Alan Cox to try to stop > the bi-daily panics I was getting on a 4GB machine. Sorry that I'm > trying to do something about our piss-poor stability. I bench marched > this change using 'uptime'. > > > > 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. > > Where the 'F' is this comming from?? I don't know why you think I am > arguing or pushing back on Alfred. I *WELCOME* people actually thinking > about our dynamic "auto-tune" limits. I just wanted to know if he had > some interested data for what ever values he'd propose. > I want to know why the limit that you chose is attributed to me and a quick suggestion that I made in an email? > Some of our "auto-tuning" hasn't 't been revisited in a long time -- back > when 128MB was "large": It was actually revisited a year ago, around the time of 5.1, but we quickly outgrew it again due to more use of UMA. > > ---------------------------- > revision 1.29 > date: 1998-02-23 07:42:40; author: dyson; state: Exp; lines: +18 -2 > Try to dynamically size the VM_KMEM_SIZE (but is still able to be > ... > Two new options "VM_KMEM_SIZE_SCALE" and "VM_KMEM_SIZE_MAX" have been > added to support better auto-sizing for systems with greater than > 128MB. > ---------------------------- > > Everytime I've asked you and phk how we should be deriving some of these > values all I get is "I don't know, but how we do it today isn't very > good". > I'll say it again. It's a hard problem. If I knew the easy answer I would have committed it long ago. Scott