On Sun, 30 Nov 2003, Jeff Roberson wrote: > On Sun, 30 Nov 2003, Colin Percival wrote: > > > Robert Watson suggested that I compare performance from UP and SMP kernels: > > > > # /usr/bin/time -hl sh -c 'make -s buildworld 2>&1' > /dev/null > > Real User Sys > > UP kernel 38m33.29s 27m10.09s 10m59.15s > > (retest) 38m33.18s 27m04.40s 11m05.73s > > SMP w/o HTT 41m01.54s 27m10.27s 13m29.82s > > (retest) 39m47.50s 27m08.05s 12m12.20s > > SMP w/HTT 42m17.16s 28m12.82s 14m04.93s > > (retest) 44m09.61s 28m15.31s 15m44.86s > > > > That enabling HTT degrades performance is not surprising, since I'm not > > passing the -j option to make; but a 5% performance delta between UP and > > SMP kernels is rather surprising (to me, at least), and the fact that the > > system time varies so much on the SMP kernel also seems peculiar. > > So you have enabled SMP on a system with one physical core and two > logical cores? Looks like almost a 20% slowdown in system time with the > SMP kernel. It's too bad it's enabled by default now. I suspect that > some of this is due to using the lock prefix on P4 cores. It makes the > cost of a mutex over 300 cycles vs 50. It might be interesting to do an > experiment without HTT, but with SMP enabled and the lock prefix > commented out. It would be interesting to compare the relative costs of: (a) De-inlining of mutex calls so that you can "plug" mutex implementations at link-time, with SMP and non-SMP versions of mutex operations, perhaps indicating with a loader which approach to take. (b) Using inlined SMP mutexes for all kernels. Would also be very interesting to have mutex contention information, and in particular, to know how much time was spent contending on Giant during the build... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert_at_fledge.watson.org Senior Research Scientist, McAfee ResearchReceived on Sun Nov 30 2003 - 17:06:00 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:32 UTC