numbers don't lie ...

[Ulrich Spoerlein]

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?