From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 18:57:01 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8A3D16A41B; Mon, 19 Nov 2007 18:57:01 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 40BF113C4DD; Mon, 19 Nov 2007 18:57:01 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <4741DC82.1090809@FreeBSD.org> Date: Mon, 19 Nov 2007 19:57:06 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Ivan Voras 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> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 18:57:02 -0000 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