From owner-freebsd-smp Fri Nov 5 19:16:12 1999 Delivered-To: freebsd-smp@freebsd.org Received: from mail.rdc2.on.home.com (ha1.rdc2.on.home.com [24.9.0.15]) by hub.freebsd.org (Postfix) with ESMTP id 43E6A14C8E for ; Fri, 5 Nov 1999 19:15:58 -0800 (PST) (envelope-from street@iname.com) Received: from mired.eh.local ([24.64.136.188]) by mail.rdc2.on.home.com (InterMail v4.01.01.07 201-229-111-110) with ESMTP id <19991106031512.VLKJ3040.mail.rdc2.on.home.com@mired.eh.local>; Fri, 5 Nov 1999 19:15:12 -0800 Received: (from kws@localhost) by mired.eh.local (8.9.3/8.9.3) id WAA76412; Fri, 5 Nov 1999 22:15:12 -0500 (EST) (envelope-from kws) To: Mike Smith Cc: freebsd-smp@FreeBSD.ORG Subject: Re: Dual Celeron + FreeBSD? References: <199911060030.QAA00895@dingo.cdrom.com> From: Kevin Street Date: 05 Nov 1999 22:15:12 -0500 In-Reply-To: Mike Smith's message of "Fri, 05 Nov 1999 16:30:59 -0800" Message-ID: <87vh7gux8f.fsf@mired.eh.local> Lines: 56 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Biscayne" Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mike Smith 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