Date: Wed, 27 Aug 2003 16:13:44 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: John Baldwin <jhb@freebsd.org> Cc: current@freebsd.org Subject: Re: HTT on current Message-ID: <20030827154738.R2144@gamplex.bde.org> In-Reply-To: <XFMail.20030826141457.jhb@FreeBSD.org> References: <XFMail.20030826141457.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 26 Aug 2003, John Baldwin wrote: > On 26-Aug-2003 Yamada Ken Takeshi wrote: > > JYI, > > I tested machdep.hlt_logical_cpus=0/1, buildworld, > > and found no particular reason to disable HTT > > as below with Zeon 2.8Ghz x 2, 1GBmem, Slow IDE HDD. > > > > It may not be the common case, so just for your info. > > > ># sysctl machdep.hlt_logical_cpus=0 > ># /usr/bin/time make -j32 buildworld > > 1910.29 real 2520.53 user 777.30 sys > > > ># sysctl machdep.hlt_logical_cpus=1 > ># /usr/bin/time make -j32 buildworld > > 2289.33 real 2666.66 user 645.88 sys > > One test is not sufficient. -current is also not the best > place to test. :) When I first implemented HTT in -current The above times seem slow enough to be partly the result of debugging options in -current. I get buildworld times ranging from 1401 seconds (2002/09/01) to 2427 seconds (2003/05/06) on Athlon XP1600 x 1 depending on configuration and tuning (but never with any expensive debugging options). A Xeon 2.8GHz x 2 should be a bit faster than an old Athlon. > ... I did 16 trials (first one was > throwaway) of back-to-back buildworlds of the same version > of -stable using make, make -j2, and make -j4 for the > following configurations: UP, HTT, HTT with smp_idle_hlt, and > HTT with pause instructions added to stable and smp_idle_hlt. > The fastest build time belonged to UP without any -j option. All benchmarks using -j are invalid because of a pessimization in make(1). It sleeps for up to SEL_USEC = 100000 usec after completion of every job (average 50 msec). With -j2 this increases !SMP buildworld times of approx. 2000 seconds by approx. 15%. I think it has a smaller effect for larger -j values and for SMP but haven't benchmarked it. This is fixed in NetBSD. I think fixing it was more urgent in NetBSD because NetBSD never changed SEL_USEC from its 4.4Lite default of 500000. 500000 was large enough to be noticeable even in 1997 when it was reduced in FreeBSD. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030827154738.R2144>