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