On 21 July 2010 06:18, Bruce Evans <b...@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 :) _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
