Date: Tue, 4 Dec 2007 13:28:50 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Ivan Voras <ivoras@freebsd.org> Cc: freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD Message-ID: <20071204130633.X87930@fledge.watson.org> In-Reply-To: <fj3f75$skn$1@ger.gmane.org> References: <20071201213732.GA16638@cannabis.dataforce.net> <1497741406.20071201230441@rulez.sk> <20071202174540.GA29572@cannabis.dataforce.net> <200712020844.49718.linimon@FreeBSD.org> <4753C9E4.1060200@chistydom.ru> <20071203114037.G79674@fledge.watson.org> <47542372.3040303@chistydom.ru> <20071203163353.J79674@fledge.watson.org> <47551C1C.3000903@chistydom.ru> <47553170.90409@bulinfo.net> <fj3f75$skn$1@ger.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 4 Dec 2007, Ivan Voras wrote: > Krassimir Slavchev wrote: > >> There is another report for such problems: >> >> http://blog.insidesystems.net/articles/2007/04/09/what-did-i-do-wrong > > Of course - FreeBSD 6.x is really bad at SMP where number of CPUs is larger > then about 2 and the loads include much kernel work (e.g. IO, context > switches). Numeric tasks (SSL) don't depend on the kernel and so they scale > ok. See http://people.freebsd.org/~kris/scaling/Scalability%20Update.pdf for > details. > > Another issue is interesting in this thread: that apparently 7.0 also has a > well defined workload where it fails. There are several known contention points that are high on the list of targets for the 8-CURRENT branch, some hopefully with MFCs in time for 7.1. These include contention on the tcbinfo lock, which protects global TCP data structures, and route table locking, which can affect high packets-per-second transmission on multiple CPUs at a time. lockmgr is high on the list for optimization also, especially since it's an older-style sleep lock constructed out of a mutex and msleep. When we optimized file descriptor locking in 7 (which mostly impacted threaded applications, and was one of the primary sources of improvement for MySQL), it had a very similar construction as lockmgr currently has, and optimization made a very big difference. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071204130633.X87930>