numbers don't lie ...

[Eric Anderson]

On 09/20/06 07:50, Oliver Fromme wrote:
> Dmitry Morozovsky wrote:
>  > Oliver Fromme wrote:
>  > > Because buildworld is I/O-bound on systems with sufficiently
>  > > fast processors.
>  > > 
>  > > Try putting the contents of /usr/src into a RAM disk and
>  > > repeat the benchmark.  The numbers might look a little
>  > > different then.  Of course, you should have sufficient RAM
>  > > in the machines -- If they're going to swap to the disks,
>  > > your benchmark won't be happy.
>  > > 
>  > > I think putting /usr/obj onto a RAM disk is _not_ necessary
>  > > because of soft-updates, so the processes shouldn't block
>  > > on writes.
>  > 
>  > My experiments show that if you have enough memory to host radmdrive for 
>  > /usr/src you'd better leave it for caching - there were no statistically
>  > meaningful performance difference, at least on machines with 1G+ RAM.
> 
> That might only be true if you have enough RAM to keep
> _all_ buildworld files (src, obj, toolchain) in the cache
> _and_ you pre-read all of /usr/src before actually starting
> the buildworld, so it is in the cache.  If you don't have
> that much RAM, but enough to store /usr/src, then using
> a RAM disk for it is a win.
> 
> 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.

Eric



-- 
------------------------------------------------------------------------
Eric Anderson        Sr. Systems Administrator        Centaur Technology
Anything that works is better than anything that doesn't.
------------------------------------------------------------------------