In message <200401112229.i0BMTkdY025963@fearless-vampire-killer.waterside.net>,
I spouted thusly:
-> In message <Pine.NEB.4.58.0401111142040.1631@rivendell.starwolf.com>, you wr
-> ite
-> :
->
-> -> Thus spake Rafal Boni ("RB> ") sometime Today...
-> ->
-> -> RB> Folks:
-> -> RB> I cvs updated last night, rebuilt a new kernel and then did a
-> -> RB> complete "build.sh distribution" on my T30 (1.8Ghz P4, 256MB
-> -> RB> RAM) leaving it to run after I went to bed. The build was
-> -> RB> done with a clean objdir, tooldir and destdirs, so every-
-> -> RB> thing was rebuilt from scratch.
-> -> RB>
-> -> RB> The build still seemed much slower than I'd expect on this
-> -> RB> hardware (I've only recently reinstalled XP to salvage some
-> -> RB> space on the disk for NetBSD, so unfortunately I don't have
-> -> RB> a good baseline, but it seems much slower than my desktop,
-> -> RB> which is a dual 700Mhz PIII with 512MB).
-> -> RB>
-> -> RB> Here's what build.sh says about the time:
-> -> RB>
-> -> RB> build.sh started: Sat Jan 10 23:14:00 EST 2004
-> -> RB> build.sh ended: Sun Jan 11 01:22:11 EST 2004
-> ->
-> -> That looks about right, actually. It takes just a bit over an hour
-> -> for my Athlon XP1900+ to build EVERYTHING; nearly 1:20:00.
-> -> 544MB core.
->
-> That's *can't* be right if what you say about your build.sh time *is*
-> right.
->
-> 1:20 for EVERYTHING (I assume this incudes the raft of kernels built as
-> part of `release', which I didn't build) on an Althlon XP1900+ (granted,
-> with 512Meg memory) vs. *over 3 hours* on a 1.8 P4 with 256MB seems rather
-> excessive. As I mentioned earlier, I thought my dual-PIII (at 700Mhz)
-> built the world faster with -j...
Heh, it would help if I got my math right :-), making my build time just
over *2* hours with the new kernel (2:08:11, if I got it right this time).
I re-ran the same build with a mid-december kernel last night (getting
lucky in that the new userland seemed to still be OK with the older
kernel) and it took almost exactly 2 hours (the box is home and off the
air now, but it was 2:00:nn for some value of nn, so it's close enough).
So it appears that the new bufcache code is responsible for *some* slow-
down, but it's on the order of 6-7% and not anything earth-shattering as
I imagined before. mrg reminded me that the source tree is ~ 500MB, so
it does look like maxing out the laptop's memory may not be a bad idea --
or at least getting one 512MB stick to push it to 768MB.
I'll try and play with the number of vnodes (which I do recall made a big
difference on my 512KB desktop machine) and maybe some of the other vm/
bufcache parameters to see if I can improve that build time any under the
new kernel, but at least I'm not seeing anything too out-of-the-ballpark.
Thanks and sorry for the confusion,
--rafal
----
Rafal Boni rafal@pobox.com
We are all worms. But I do believe I am a glowworm. -- Winston Churchill