svn commit: r210217 - head/sys/kern

[Ivan Voras]

On 21 July 2010 06:18, Bruce Evans <brde at optusnet.com.au> wrote:
> 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 previous ratio of lorunningspace to hirunningspace was 1/2 - is
this still a good target?

> 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...

It does seem like there would be more benefitial to hang these
variables per mount-point or something similar but I'm content that
they are tunable and that the new values help high-end machines,
probably in cooperation with tagged (NCQ-like) IO.

>> Presumably you could use 'lmax(lmin(..., 16 * 1024 * 1024), 1024 *
>> 1024))'?
>
> Better.

> Normal formatting is sometimes broken to avoid lines longer than 80
> characters.  This works here.  I don't like this.

Yes, this was the reason for the original patch's formatting :)