From owner-cvs-src@FreeBSD.ORG Tue Aug 3 01:12:42 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 697BB16A4CE; Tue, 3 Aug 2004 01:12:42 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0383443D41; Tue, 3 Aug 2004 01:12:42 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.0.12] (g4.samsco.home [192.168.0.12]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i731Je8b037503; Mon, 2 Aug 2004 19:19:40 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <410EE627.8090105@freebsd.org> Date: Mon, 02 Aug 2004 19:11:03 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David E. O'Brien" References: <200408022152.i72Lqhig042925@repoman.freebsd.org> In-Reply-To: <200408022152.i72Lqhig042925@repoman.freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: src-committers@freebsd.org cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/kern vfs_subr.c 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, 03 Aug 2004 01:12:42 -0000 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. Scott