svn commit: r210217 - head/sys/kern

[Bruce Evans]

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