Blair Sadewitz | 2 Apr 2007 03:15
Picon

LFS "smooth" syncer workaround/performance tuning

I'd grown annoyed at how LFS would blast data to the disk according to
vfs.sync.*delay settings. A while ago, I thought, "why not just
disable the sync delay altogether?"  Try setting:

vfs.sync.delay = 0
vfs.sync.filedelay = 0
vfs.sync.metadelay = 0
vfs.sync dirdelay = 0

Then, find out how much bandwidth you have at the inside and outside
of your disk.  That is, run newfs_lfs -ANF on a partition close to
cylinder 0, then do the same on a partition close to the last
cylinder.  Average the two, then calculate the LFS "page trip" with
the following formula (thanks tls):

t=(avg_bandwidth_in_bytes / PAGE_SIZE) / 4

I'd imagine that averaging is more or less moot if you don't plan on
using > %50 of your disk's capacity, or if you are using a partition
smaller than a majority of the disk.

Set vfs.lfs.pagetrip=t, and notice how data is now written much more
smoothly to the disk.  You can fiddle with vfs.lfs.pagetrip according
to the amount of latency you want.  This works especially well with
BUFQ_PRIOCSCAN or BUFQ_READPRIO.  For further optimization, I'd
recommend using BUFQ_PRIOCSCAN and tweaking the burst values using
xtraeme's bufq sysctl patch:

http://www.xtrarom.org/patches/bufq_sysctl.diff

(Continue reading)

Blair Sadewitz | 2 Apr 2007 03:30
Picon

Re: LFS "smooth" syncer workaround/performance tuning addendum

I forgot to mention that this seems to be especially beneficial if I'm
looking to disable write-back caching on a wd(4) device.  Data is
written in much smaller chunks, so the backlog seems to be much more
manageable.

I haven't tested this much, though.

--Blair

--

-- 
Support WFMU-FM: free-form radio for the masses!
<http://www.wfmu.org/>

"The frivolity and boredom which unsettle the established order, the
vague foreboding of something unknown, these are the heralds of
approaching change.  The gradual crumbling that left unaltered the
face of the whole is cut short by a sunburst which, in one flash,
illuminates the features of the new world."  --G.W.F. Hegel,
_Phenomenology of Spirit_ 5:11

Juan RP | 3 Apr 2007 10:00

Re: LFS "smooth" syncer workaround/performance tuning

This patch for bufq+sysctl is not optimal because it should be using values 
per-drive
not globally, perhaps in the future I'll do it correctly...

----- Original Message ----- 
From: "Blair Sadewitz" <blair.sadewitz <at> gmail.com>
To: <tech-perform <at> netbsd.org>; <current-users <at> netbsd.org>
Sent: Monday, April 02, 2007 3:15 AM
Subject: LFS "smooth" syncer workaround/performance tuning

> I'd grown annoyed at how LFS would blast data to the disk according to
> vfs.sync.*delay settings. A while ago, I thought, "why not just
> disable the sync delay altogether?"  Try setting:
>
> vfs.sync.delay = 0
> vfs.sync.filedelay = 0
> vfs.sync.metadelay = 0
> vfs.sync dirdelay = 0
>
> Then, find out how much bandwidth you have at the inside and outside
> of your disk.  That is, run newfs_lfs -ANF on a partition close to
> cylinder 0, then do the same on a partition close to the last
> cylinder.  Average the two, then calculate the LFS "page trip" with
> the following formula (thanks tls):
>
> t=(avg_bandwidth_in_bytes / PAGE_SIZE) / 4
>
> I'd imagine that averaging is more or less moot if you don't plan on
> using > %50 of your disk's capacity, or if you are using a partition
> smaller than a majority of the disk.
(Continue reading)

Blair Sadewitz | 3 Apr 2007 14:26
Picon

Re: LFS "smooth" syncer workaround/performance tuning

It helps me out sufficiently, as I'm using an LFS ccd on three
identical drives. ;)

--Blair

--

-- 
Support WFMU-FM: free-form radio for the masses!
<http://www.wfmu.org/>

"The frivolity and boredom which unsettle the established order, the
vague foreboding of something unknown, these are the heralds of
approaching change.  The gradual crumbling that left unaltered the
face of the whole is cut short by a sunburst which, in one flash,
illuminates the features of the new world."  --G.W.F. Hegel,
_Phenomenology of Spirit_ 5:11


Gmane