Date: Fri, 22 Sep 2006 20:44:35 +0200 From: Ulrich Spoerlein <uspoerlein@gmail.com> To: freebsd-hackers@FreeBSD.ORG Subject: Re: numbers don't lie ... Message-ID: <20060922184435.GA1250@roadrunner.q.local> In-Reply-To: <200609210831.k8L8VxvK007258@lurza.secnetix.de> References: <451140F8.9030500@centtech.com> <200609210831.k8L8VxvK007258@lurza.secnetix.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Oliver Fromme wrote: > Eric Anderson wrote: > > Oliver Fromme wrote: > > > 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. .. which makes no difference for the test case presented here. You're missing the point here: they benchmark with '-j8'. If you'd benchmark a -j1 build of md(4) vs. real disks, then you should get drastically different results (provided you start with a cold cache). But on these dual (quad?) CPU machines, with a -j8 build, 6 threads/processes are free to wait for disk I/O a very long time till they are finally scheduled. Thus, specifying high -jN values will mask any disk I/O latency (for reasonable combinations of CPUs and HDDs). Ulrich Spoerlein -- A: Yes. >Q: Are you sure? > >A: Because it reverses the logical flow of conversation. > >>Q: Why is top posting frowned upon?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060922184435.GA1250>