From owner-freebsd-arch@FreeBSD.ORG Wed Oct 10 06:13:06 2007 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3996416A41A; Wed, 10 Oct 2007 06:13:06 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 040B513C467; Wed, 10 Oct 2007 06:13:05 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.103] (c-67-160-44-208.hsd1.wa.comcast.net [67.160.44.208]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l9A6D32c028080 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Wed, 10 Oct 2007 02:13:05 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Tue, 9 Oct 2007 23:15:38 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: David Xu In-Reply-To: <470C2DC5.3040601@freebsd.org> Message-ID: <20071009231203.I912@10.0.0.1> References: <20071008142928.Y912@10.0.0.1> <470C2DC5.3040601@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org Subject: Re: Abolishing sleeps in issignal() X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2007 06:13:06 -0000 On Wed, 10 Oct 2007, David Xu wrote: > I think the performance problem here is that while sleep queue lock is > already hash scaled, but interruptable msleep still has to pass through > a single lock, the process lock, this is a serious serialization problem on > SMP machine, especially when machine has 4 or more cores. > Also in most most runtime, process has few signals and job controls, > process lock and unlock should be avoided by checking a thread self's > flag instead, which uses thread lock. > This is an interesting approach as well and may have some value, however, I hope to fix a number of bugs in the current mechanism at the same time. This will still require moving the sleeps. I also intend to experiment with making the sigaction lock a spinlock and using that entirely to protect signal delivery for the process. This will make a single spinlock which can be checked while the sleepq chain lock is held. Solaris actually does this without a lock entirely. If the race is lost the sender of the signal will be blocking on the sleepq chain lock while the thread is going to sleep anyway. I think this is possible to implement without much difficulty. > I had ever worked out a patch to avoid the lock contention: > http://people.freebsd.org/~davidxu/patch/PCATCH_optimize.patch > > mysql benchmark shows that on dual PIII machine it can improve > performance about 1 or 2 percentage, I had not tested it on 4 core > machine. We have seen that faster machines suffer much more from the contention problems so it's likely that the effect would be significantly greater on a 4-8 core faster machine. If you update the patch I can try it on an 8way opteron or xeon for you. > > Regards, > David Xu > Thanks, Jeff