From owner-freebsd-stable@FreeBSD.ORG Tue Dec 11 12:59:09 2007 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C18316A420 for ; Tue, 11 Dec 2007 12:59:09 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2001:1b20:1:3::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9CF5F13C4CC for ; Tue, 11 Dec 2007 12:59:08 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id lBBCx0PO085482; Tue, 11 Dec 2007 13:59:06 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id lBBCx0Ld085481; Tue, 11 Dec 2007 13:59:00 +0100 (CET) (envelope-from olli) Date: Tue, 11 Dec 2007 13:59:00 +0100 (CET) Message-Id: <200712111259.lBBCx0Ld085481@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, killing@multiplay.co.uk In-Reply-To: <00e201c83349$b94ab7d0$b6db87d4@multiplay.co.uk> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 11 Dec 2007 13:59:07 +0100 (CET) Cc: Subject: Re: Also seeing 2 x quad-core system slower that 2 x dual core X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, killing@multiplay.co.uk List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2007 12:59:09 -0000 Steven Hartland wrote: > sysctl -a |grep dirhash > > Check vfs.ufs.dirhash_mem is not close to vfs.ufs.dirhash_maxmem if it is > and only most used boxes this seems to be the case increase maxmem. > > Seems this could either do with an auto tune option or a larger max by > default in today's day and age. I think it would make sense to tie it to the maxusers value (which in turn depends on the amount of RAM, by default). For example, setting dirhash_maxmem to maxusers/32 MB with a lower limit of 2 MB seems reasonable. By default, the maximum of the autotuned maxuers value is 384, so the auto- tuned value of dirhash_maxmem would be between 2 and 12 MB, depending on the amount of RAM. Of course the admin could still adjust it manually if required. I.e. something like this: --- ufs_dirhash.c.orig 2005-10-31 16:41:28.000000000 +0100 +++ ufs_dirhash.c 2007-12-11 13:56:05.000000000 +0100 @@ -1074,6 +1074,9 @@ void ufsdirhash_init() { + ufs_dirhashmaxmem = maxusers * (1024 * 1024 / 32); + if (ufs_dirhashmaxmem < 2 * 1024 * 1024) + ufs_dirhashmaxmem = 2 * 1024 * 1024; ufsdirhash_zone = uma_zcreate("DIRHASH", DH_NBLKOFF * sizeof(doff_t), NULL, NULL, NULL, NULL, UMA_ALIGN_PTR, 0); mtx_init(&ufsdirhash_mtx, "dirhash list", NULL, MTX_DEF); I haven't actually tried that, though, but the patch is trivial enough so there shouldn't be too many bugs. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd We're sysadmins. To us, data is a protocol-overhead.