Date: Sun, 22 Mar 1998 11:50:51 -0800 (PST) From: Simon Shapiro <shimon@simon-shapiro.org> To: Andrew Reilly <reilly@zeta.org.au> Cc: current@FreeBSD.ORG, taob@nbc.netcom.ca Subject: Re: Worldstone Continued... Message-ID: <XFMail.980322115051.shimon@simon-shapiro.org> In-Reply-To: <199803220833.TAA14256@gurney.reilly.home>
next in thread | previous in thread | raw e-mail | index | archive | help
On 22-Mar-98 Andrew Reilly wrote: > On 21 Mar, Simon Shapiro wrote: >> My very humble opinion is that we are barking up the wrong tree. Disk >> I/O >> is not the limiting factor here. I am looking at disk bandwidth >> utilization of less than 20%. From idle observation, it appears that >> parsing Makefiles is 4-5 times the amount of time it takes to actually >> compile anything. >> >> The curious could take the kernel directory and write a simple script >> to >> compile it without make at all. Tell us the results. > > For the kernel, that's nothing more than the output of make -n. I > think that building a script for make buildworld could be a little > trickier. > > I'm a little surprised that you think that make itself is so > expensive. Simple observation; make clean && make depend && make -j8 in the kernel. Observe the relative time it takes make to prepare what to do, and the time it takes to actually compile it. Another Observation; I can increase disk bandwidth for large compilations (make world, etc.) almost linearly with only minimal gain in overall time. I compiled on RAID-5, RAID-0, with stripe width up to 8 drives, with source and objects on separate arrays. WRITE cache is set to write-back, the system can demonstrate 5-19 MB/Sec for random I/O on small blocks, up to 1740 disk ops/sec. Make buildworld and make -j8buildworld are resulting in 200, 280 disk I/O ops/sec, respectively. CPU utilization is 80% user 70% system (figure this one out :-). I conclude from these numbers that the system is not starved for I/O. There could be one of several explanations: * Make, which is low-I/O consumer, takes inordinate amount of time * Compilations are CPU intensive, more than we think * The current SCSI layer is somehow slow I wish I had the time to port the DPT driver to CAM. This will give us an answer. ---------- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.980322115051.shimon>