Abolishing sleeps in issignal()

[Jeff Roberson]

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