Date: Tue, 9 Oct 2007 23:15:38 -0700 (PDT) From: Jeff Roberson <jroberson@chesapeake.net> To: David Xu <davidxu@FreeBSD.org> Cc: arch@FreeBSD.org Subject: Re: Abolishing sleeps in issignal() Message-ID: <20071009231203.I912@10.0.0.1> In-Reply-To: <470C2DC5.3040601@freebsd.org> References: <20071008142928.Y912@10.0.0.1> <470C2DC5.3040601@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071009231203.I912>