[...]
> 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
you might have a point, but this started when I asked why, two
boxes, under similar test gave idential real times, but very different
user times.
dell-2950 : make -j8 TARGET_ARCH=amd64 buildworld:
24m8.28s real 1h2m59.38s user 16m16.20s sys
sunfire : make -j8 TARGET_ARCH=amd64 buildworld:
23m47.69s real 48m53.58s user 13m44.81s sys
and
SUN X4100: Dual Core AMD Opteron(tm) Processor 280 (2393.19-MHz
K8-class CPU)
one 70g sas disk (via mpt) -- x 2
DELL 2950: Intel(R) Xeon(TM) CPU 3.20GHz (3192.98-MHz K8-class CPU)
4 sata disks + raid0 (via mfi) -- dual core x 2
cheers,
danny
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
