Re: numbers don't lie ...


KK> > My experiments show that if you have enough memory to host radmdrive for
KK> > /usr/src you'd better leave it for caching - there were no statistically
KK> > meaningful performance difference, at least on machines with 1G+ RAM.
KK>
KK> Really? My measurements show the opposite (on a system with 16GB of
KK> RAM).

My last test on amd64/dualcore with 4G of RAM and -j4 shows
(buildworld+buildkernel):

==> /tmp/buildlog <==
1996.45 real 3032.94 user 624.83 sys
Script done on Tue Sep 19 14:44:54 2006

==> /tmp/buildlog.md <==
1957.45 real 3033.93 user 585.78 sys
Script done on Tue Sep 19 15:20:42 2006

Second one was with 512M/4k/512 swap-backed md, the former with /usr/src on the
gmirror'ed pair of SATAs.

In both cases, the amount of processing was the same ('user' times are
remarkably close to each other: ~3033.5 CPU-seconds), because the source
code didn't change. However, in the first case additional 39 seconds were
spent in kernel ('sys'), which made the whole compile process be 39 seconds
slower in real time. Notice how {(3033.93/2)+585.78=2102.745} > {1957.45}.
Where had those 'extra' 145.3 seconds gone? 2 possibilities:

0a. The number of cores is not 2, but 2.21 rather, meaning that each
core is loaded 110.6% (i.e., each CPU-second of computations takes
noticeably less than 1 second of real time to complete, assuming
100% load). This is impossible. Changes in user time should always
track changes in real time.
0b. 'Sys' time calculation might not be totally independent of
'user' time.

So, I say if 0a is somehow true, then the setup is likely CPU-bound, but
if 0b is true, then it's probbly IO-ound. Well, I suppose it's hitting
both limits at times, as swapping seems to be present too. My logic could
be broken here, though, 'cause it's 04:00 in the morning...

Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]

[SorAlx] ridin' VN1500-B2
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"