From owner-freebsd-threads@FreeBSD.ORG Tue Jun 15 21:18:13 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 76BA416A4CE for ; Tue, 15 Jun 2004 21:18:13 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27A7E43D58 for ; Tue, 15 Jun 2004 21:18:13 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i5FLGrCZ073445; Tue, 15 Jun 2004 17:16:53 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i5FLGrcC073442; Tue, 15 Jun 2004 17:16:53 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 15 Jun 2004 17:16:53 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Daniel Eischen In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: Possible Threading problem with -CURRENT / MySQL? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2004 21:18:13 -0000 On Tue, 15 Jun 2004, Daniel Eischen wrote: > > My results were without HTT (It was FreeBSD-AMD64) I didn't have any memory > > options > > or a mysql config file. > > > > _This problem is directly related to a commit that was made between ~May 18 > > and yesterday._ > > There was a subsystem lock(s) put in for networking a few days ago. > There were no changes to the threads library that would exhibit the > behavior you are seeing. The candidate time range includes a number of big and relevant changes: - mbuma becomes the mbuf allocator, which would affect heavy UNIX domain socket I/O since mbufs are used for that I/O on local mysql configurations. Since general benchmarks I've seen suggest mbuma helps or has the same cost as the previous allocator, presumably it would be some special case regression. - Coarse-grained locking was introduced in UNIX domain sockets, but Giant has not yet been removed. This means we're paying an additional (and redundant) locking overhead without the benefits of the finer-grained locking model in the base tree. I've set up a test box to look at the performance impact of that today to see if it resulted in a substantial regression. I'd expect a few percent, but maybe it's worse and it would be good to know. - There have been a number of amd64-related VM changes, optimizations, etc. Maybe one didn't work out so well. I don't have an amd64-box so I can't really reason about that too much just now. If we can track down the date a little closer, that would help a lot. Even just adding a new data point for June 1 or June 7 would be helpful. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research