Date: Mon, 12 Oct 1998 06:18:43 -0700 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Eivind Eklund <eivind@yes.no>, Mike Smith <mike@smith.net.au>, Bruce Evans <bde@zeta.org.au> Cc: Don.Lewis@tsc.tdk.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG, gibbs@plutotech.com, tlambert@primenet.com Subject: Re: filesystem safety and SCSI disk write caching Message-ID: <199810121318.GAA09733@salsa.gv.tsc.tdk.com> In-Reply-To: Eivind Eklund <eivind@yes.no> "Re: filesystem safety and SCSI disk write caching" (Oct 4, 3:25pm)
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 4, 3:25pm, Eivind Eklund wrote:
} Subject: Re: filesystem safety and SCSI disk write caching
} On Sun, Oct 04, 1998 at 12:06:15AM -0700, Mike Smith wrote:
} > > >> Yes, the default configuration may be much slower than mine.
} > > >
} > > >I can definitely back your basic point ('make world' is CPU bound) up.
} > > >On a 4-way Xeon system with slow disks we were still able to get down
} > > >around 40 minutes.
} > >
} > > Er, that shows that it is i/o bound on systems with so much CPU. I
} > > got it down to 75 minutes on 1-way K6-233 with 1 IDE disk before it
} > > was bloated by perl5 and transition to elf.
} >
} > Moving to an MFS only saved about 15% of the build time. My point was
} > that a faster CPU let you go faster. If the build was I/O bound, it
} > wouldn't.
}
} My hypothesis is that for the high end boxes, 'make world' is mostly
} bound by memory bandwidth. This is what seems to best match the speed
} patterns people have been reporting.
I don't think that's it either. One would certainly hope that a 4-way
Xeon system would have more than twice as much memory bandwidth as
a K6-233.
I'm getting times down around 92 minutes with a Pentium II - 266 and
a single Seagate Hawk when building FreeBSD post elf and perl5. That
should get the times down to under 60 minutes with a Pentium II - 450.
My conclusion is that running FreeBSD on a 4-way Xeon is not a cost
effective way to get buildworld to run faster ...
Here are some statistics that I gathered by varying the mount options
on /usr/obj and rerunning make buildworld. It now looks like enabling
SCSI write caching makes even less difference in the timing than I
originally thought (a maximum of about 4 minutes with standard mount
options, and a maximum of about 1 minute with either softupdates or
async, typically much less). Also, softupdates is generally faster
than async.
I haven't yet had time to try to track down why "make -j4 buildworld"
fails with the standard mount options.
make -j1 -j2 -j3 -j4 -j6 -j8 -j12
/usr/obj mount options +
SCSI write caching
standard 158:04 133:33 129:56 FAIL *126:09 127:58 128:42
standard+write-cache 154:54 131:58 126:13 FAIL *115:44 123:44 126:24
softupdates 126:23 96:36 93:33 92:38 92:02 91:50 92:12
softupdates+write-cache 125:58 95:10 92:32 91:54 91:18 91:10 91:35
async 127:06 96:40 93:27 92:45 91:59 92:07 92:15
async+write-cache 125:18 95:54 92:56 92:05 91:26 91:24 91:36
Times in MMM:SS.
All "make buildworld" runs started with a full object tree except:
* partial object tree because of failure during previous run
Hardware:
Pentium II - 266
64 MB RAM
Adaptec 2940UW
Seagate ST-32151N Hawk 2XL Fast SCSI-2 (10.0MB/s transfer rate)
Software:
FreeBSD 3.0-BETA from September 26 with softupdates fixes and CAM.
The softupdates times may be somewhat pessimistic because the code
still has a number of sanity checks that I inserted to track down the
newdirrem panic.
All partitions mounted with standard mount options except /tmp which used
mfs (and "setenv TMPDIR /tmp") and /usr/obj whose mount options were varied.
All partitions were on the same spindle.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810121318.GAA09733>