From owner-freebsd-threads@FreeBSD.ORG Mon Nov 15 12:55:52 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD83316A4CE; Mon, 15 Nov 2004 12:55:52 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59FCC43D41; Mon, 15 Nov 2004 12:55:52 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) iAFCtnsu002500; Mon, 15 Nov 2004 07:55:49 -0500 (EST) Date: Mon, 15 Nov 2004 07:55:49 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Robert Watson In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: threads@freebsd.org cc: Julian Elischer Subject: Re: [Fwd: Re: Mysql - Linuxthreads : Still needed?] X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2004 12:55:52 -0000 On Mon, 15 Nov 2004, Robert Watson wrote: > > On Wed, 10 Nov 2004, Julian Elischer wrote: > > > send to the right list. > > So, the good news is that we've successfully dramatically improved the > performance of MySQL between 5.2 and 5.3. The mixed news is that clearly > we have more work to do. :-) Out of curiousity, has anyone done much in > the way of kernel profiling during heavy duty MySQL runs to see if there > are specific kernel bottlenecks we can be working on? > > I've noticed that we're contending a fair amount on UNIX domain socket > locking, although with Giant off the stack this is a big improvement over > what we saw previously. Although it was a few months ago, my recollection > from profiling the mutex use and kernel use is that we're spending a lot > of time checking to see if we have to deliver signals to threads or not in > kernel. I may have the opportunity to do a bit of profiling today or > tomorrow and see what I bump into. David did a bit of research and found that in M:N cases there is a lot of contention for upcall allocation (actually I think it is thread allocation) in the kernel. It looks like we completely teardown and free completed threads, then reallocate and set them up again when they unblock and we need a new thread to convert into an upcall. It would probably be faster to cache them (hang them off the KSE group) instead of completely tearing them down and deallocating them. -- Dan Eischen