Date: 05 Nov 1999 22:15:12 -0500 From: Kevin Street <street@iname.com> To: Mike Smith <mike@smith.net.au> Cc: freebsd-smp@FreeBSD.ORG Subject: Re: Dual Celeron + FreeBSD? Message-ID: <87vh7gux8f.fsf@mired.eh.local> In-Reply-To: Mike Smith's message of "Fri, 05 Nov 1999 16:30:59 -0800" References: <199911060030.QAA00895@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Smith <mike@smith.net.au> writes:
> > > Under 40 minutes is very hard on a current intel architecture box; the
> > > 4-way Xeon 400/256 that we have here will do about 39 even on -current
> > > as of a couple of weeks ago, with everything except $DESTDIR on an MFS.
> > >
> > > To go much faster will require more memory bandwidth, or possibly
> > > faster CPUs with more cache (not so sure about that part).
> > ...
> > 2384.21 real 2809.03 user 1337.21 sys
> > elapsed 0:39:42 busy 86.95%
> >
> > Ok, so I cheated with -DNOPROFILE and I have a somewhat modified
> > bsd.subdir.mk that parallelizes some subdir builds in the "building
> > everything" phase of the make. This is with a dual 466 Celeron, 128M
> > 66Mhz FSB, no overclocking, Abit BP6. I'm using -pipe in
> > /etc/make.conf and /usr/src, /usr/obj and /tmp are all on a striped
> > vinum volume that resides on 2 IBM 9G 7200RPM SCSI drives with
> > softupdates.
>
> So stop cheating. I can get it down to a few hundredths of a second
> if I rewrite make thus:
>
> void main(void) { return(0); }
heh, I thought you'd get grumpy when I posted that :)
Ok, without the -DNOPROFILE it's 44:03
I really had 2 points:
1) Dual Celeron's do work pretty well given a good workload
2) Your assertion that we need more memory bandwidth to go much faster
on the buildworld - I disagree, or at least I think we have not wrung
all the SMP performance out of build world that we should. One big
problem with make -j N is that it does ok at parallelizing the compile
of large subdirectories with lots of C modules since it starts many
compiles at once. The link step seriallizes however, which means
that the 2nd (& 3rd and 4th) cpus sit mostly idle. The same thing
happens when building small subdirs with only one, or a few, c modules.
And when the build moves between subdirs it seriallizes while it
interprets the make file and sets up the parallel compiles etc.
The net result on my system is that the build runs at about 70% cpu
utilization overall, ie I get a max of 140% of the single cpu.
Actually less because of the SMP overhead. By some relatively simple
tweaking of the build rules, starting multiple subdir makes in
parallel, we can get much better parallelization since while one subdir
is seriallizing, the others can be running on the other cpus. With my
experimental version I'm getting the average cpu up to about 87% ie
getting about 178% of the single cpu. Actually the last half of the
buildworld runs at about 100% utilization. The first half (building
the tools and some libs) is still seriallized quite a bit since I have
not tinkered with that part yet.
--
Kevin Street
street@iname.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?87vh7gux8f.fsf>