Date: Wed, 21 Jul 2010 11:04:37 +0200 From: Ivan Voras <ivoras@freebsd.org> To: Bruce Evans <brde@optusnet.com.au> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, John Baldwin <jhb@freebsd.org> Subject: Re: svn commit: r210217 - head/sys/kern Message-ID: <AANLkTilQm_nP-GAd-KHJPjdJcB8gX58dnI7f6xmpCpJp@mail.gmail.com> In-Reply-To: <20100721134319.E7228@delplex.bde.org> References: <201007181015.o6IAFXvK018739@svn.freebsd.org> <201007190829.21995.jhb@freebsd.org> <20100721134319.E7228@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 21 July 2010 06:18, Bruce Evans <brde@optusnet.com.au> wrote: > On Mon, 19 Jul 2010, John Baldwin wrote: > >>> Log: >>> =C2=A0In keeping with the Age-of-the-fruitbat theme, scale up hirunning= space >>> on >>> =C2=A0machines which can clearly afford the memory. >>> >>> =C2=A0This is a somewhat conservative version of the patch - more fine = tuning >>> may be >>> =C2=A0necessary. >>> >>> =C2=A0Idea from: Thread on hackers@ >>> =C2=A0Discussed 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. =C2=A0getblk() often takes many seco= nds, > and occasionally takes a couple of _minutes_. =C2=A0dvd's aren't quite th= at > slow, and can easily write hirunningspace =3D 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. =C2=A0This works here. =C2=A0I don't like this. Yes, this was the reason for the original patch's formatting :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTilQm_nP-GAd-KHJPjdJcB8gX58dnI7f6xmpCpJp>