Date: Wed, 20 Sep 2006 04:04:23 -0700 From: soralx@cydem.org To: freebsd-hackers@freebsd.org Subject: Re: numbers don't lie ... Message-ID: <200609200404.23618.soralx@cydem.org> In-Reply-To: <20060920123940.W63482@woozle.rinet.ru> References: <200609141232.k8ECWTXj045191@lurza.secnetix.de> <20060919173421.GA45928@xor.obsecurity.org> <20060920123940.W63482@woozle.rinet.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200609200404.23618.soralx>