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? _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
