Date: Mon, 19 Nov 2007 19:57:06 +0100 From: Kris Kennaway <kris@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: <4741DC82.1090809@FreeBSD.org> In-Reply-To: <fhslf4$oss$1@ger.gmane.org> References: <4741905E.8050300@chistydom.ru> <20071119140019.V80667@fledge.watson.org> <4741A3A8.4010803@chistydom.ru> <20071119152214.J80667@fledge.watson.org> <4741B648.7090002@chistydom.ru> <4741D4D2.4090902@FreeBSD.org> <fhslf4$oss$1@ger.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Ivan Voras wrote: > Kris Kennaway wrote: > >> My guess is that you're hitting contention in the TCP send path, but I >> missed the start of this conversation so I don't know what problems you >> are seeing. > > Here it is: > http://lists.freebsd.org/pipermail/freebsd-stable/2007-November/038371.html > > there's some mutex profiling there. OK, but that is on 6.x and only (I guess) on the 8 core machine. What is needed is at least a comparison of the two machines under identical conditions, and preferably on 7.0. It looks like the most serious issue might be due to lockmgr contention, but on 6.x lockmgr usage is not profiled directly (it only shows up via secondary mutexes). Comparing two 7.0 traces should help to shed more light on the subject. > Offtopic: How to you read output from debug.mutex.prof.stats? Is > cnt_lock the number of times a lock has been attempted to be acquired > but it wasn't available? It's explained in the MUTEX_PROFILING(9) manpage (LOCK_PROFILING(9) on 7.0) cnt_hold The number of times the lock was held and another thread attempted to acquire the lock. cnt_lock The number of times the lock was already held when this point was reached. Kris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4741DC82.1090809>