Re: numbers don't lie ...
- From: Ulrich Spoerlein <uspoerlein@xxxxxxxxx>
- Date: Fri, 22 Sep 2006 20:44:35 +0200
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?
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"
- References:
- Re: numbers don't lie ...
- From: Eric Anderson
- Re: numbers don't lie ...
- From: Oliver Fromme
- Re: numbers don't lie ...
- Prev by Date: Re: fsck
- Next by Date: Re: fsck
- Previous by thread: Re: numbers don't lie ...
- Next by thread: Re: numbers don't lie ...
- Index(es):
Relevant Pages
|