From owner-svn-src-head@FreeBSD.ORG Wed Jul 21 04:18:18 2010 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B94FD1065675; Wed, 21 Jul 2010 04:18:18 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by mx1.freebsd.org (Postfix) with ESMTP id 4CA0D8FC21; Wed, 21 Jul 2010 04:18:17 +0000 (UTC) Received: from c122-106-145-25.carlnfd1.nsw.optusnet.com.au (c122-106-145-25.carlnfd1.nsw.optusnet.com.au [122.106.145.25]) by mail06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o6L4IDCG026215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jul 2010 14:18:14 +1000 Date: Wed, 21 Jul 2010 14:18:13 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: John Baldwin In-Reply-To: <201007190829.21995.jhb@freebsd.org> Message-ID: <20100721134319.E7228@delplex.bde.org> References: <201007181015.o6IAFXvK018739@svn.freebsd.org> <201007190829.21995.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Ivan Voras Subject: Re: svn commit: r210217 - head/sys/kern X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 04:18:18 -0000 On Mon, 19 Jul 2010, John Baldwin wrote: >> Log: >> In keeping with the Age-of-the-fruitbat theme, scale up hirunningspace on >> machines which can clearly afford the memory. >> >> This is a somewhat conservative version of the patch - more fine tuning may be >> necessary. >> >> Idea from: Thread on hackers@ >> Discussed with: alc Sorry I didn't look at the thread, but I wonder if you should increase lorunningspace similarly. The vfs_bio sysctls are not easy to tune. The only time I tried changing them much was in connection with nfs. Congestion caused i/o to not stream. IIRC the problem was mostly that too many nfsiods ran and they got in each others way, and increasing hirunningspace only helped by making the problem more obvious -- it allowed longer bursts of the network part of the i/o but longer idle periods too. There is a possibly related problem with writing through file systems to high-latency disk devices like dvds. getblk() often takes many seconds, and occasionally takes a couple of _minutes_. dvd's aren't quite that slow, and can easily write hirunningspace = 1MB in 1 second, except possibly if the file system is not designed for high-latency devices (like most including cd9660 and udf are :-() so it does lots of random i/o). The above is mostly for 1 active file system... >> >> Modified: >> head/sys/kern/vfs_bio.c >> >> Modified: head/sys/kern/vfs_bio.c >> ============================================================================== >> --- head/sys/kern/vfs_bio.c Sun Jul 18 08:54:31 2010 (r210216) >> +++ head/sys/kern/vfs_bio.c Sun Jul 18 10:15:33 2010 (r210217) >> @@ -621,7 +621,9 @@ bufinit(void) >> lobufspace = hibufspace - MAXBSIZE; >> >> lorunningspace = 512 * 1024; >> - hirunningspace = 1024 * 1024; >> + hirunningspace = lmin(roundup(hibufspace/64, MAXBSIZE), 16*1024*1024); >> + if (hirunningspace < 1024 * 1024) >> + hirunningspace = 1024 * 1024; ... dvds are plenty slow enough to take many seconds to write hirunningspace = 16MB, even for purely sequential writes. Floppy disks are slower and would take 16*33 seconds :-). So although faster disks and multiple disks need a larger hirunningspace, a large hirunningspace is not good while it is global (it should probably be per-active-disk). If there is just one active-for-writes slow disk in the system, writes to it alone are almost sure to build up (since writes to the faster disks will complete faster), so that soon all of hirunningspace is allocated to the slow disk. Something like this happens in my dvd example. > Presumably you could use 'lmax(lmin(..., 16 * 1024 * 1024), 1024 * 1024))'? Better. > Also, the common style throughout the kernel is to provide spaces around > operators like '/' and '*'. The Normal style is still used in adjacent lines. Normal formatting is sometimes broken to avoid lines longer than 80 characters. This works here. I don't like this. Bruce