Date: Thu, 21 Sep 2006 10:31:59 +0200 (CEST) From: Oliver Fromme <olli@lurza.secnetix.de> To: freebsd-hackers@FreeBSD.ORG Subject: Re: numbers don't lie ... Message-ID: <200609210831.k8L8VxvK007258@lurza.secnetix.de> In-Reply-To: <451140F8.9030500@centtech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Eric Anderson wrote: > Oliver Fromme wrote: > > Dmitry Morozovsky wrote: > > > > Because buildworld is I/O-bound on systems with sufficiently > > > > fast processors. > > > > > > > > Try putting the contents of /usr/src into a RAM disk and > > > > repeat the benchmark. The numbers might look a little > > > > different then. Of course, you should have sufficient RAM > > > > in the machines -- If they're going to swap to the disks, > > > > your benchmark won't be happy. > > > > > > > > I think putting /usr/obj onto a RAM disk is _not_ necessary > > > > because of soft-updates, so the processes shouldn't block > > > > on writes. > > > > > > My experiments show that if you have enough memory to host radmdrive for > > > /usr/src you'd better leave it for caching - there were no statistically > > > meaningful performance difference, at least on machines with 1G+ RAM. > > > > That might only be true if you have enough RAM to keep > > _all_ buildworld files (src, obj, toolchain) in the cache > > _and_ you pre-read all of /usr/src before actually starting > > the buildworld, so it is in the cache. If you don't have > > that much RAM, but enough to store /usr/src, then using > > a RAM disk for it is a win. > > > > Reading /usr/src from a physical disk certainly requires > > quite some I/O that takes more than zero time. > > But, in order to populate the ram disk, you must read /usr/src also from > something, and that also takes time, which you should include in the > full scope. But when you perform the buildworld several times (as you should do when you're benchmarking properly), everything is already in the RAM disk. If you instead rely on caching but you don't have enough RAM to hold all of src + obj + toolchain in RAM, then src (or at least parts of it) will have to be read from the physical disk again upon each buildworld. By the way, the contents of the RAM disk are _not_ cached in RAM, so they don't waste RAM twice. That was only a problem with the old vn(4)/vnconfig(8) in FreeBSD 4. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "IRIX is about as stable as a one-legged drunk with hypothermia in a four-hundred mile per hour wind, balancing on a banana peel on a greased cookie sheet -- when someone throws him an elephant with bad breath and a worse temper." -- Ralf Hildebrandt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200609210831.k8L8VxvK007258>