cvs commit: src/lib/libthr/thread thr_cond.c thr_private.h thr_rwlock.c

[Jeff Roberson]

On Tue, 1 Apr 2008, David Xu wrote:

> Jeff Roberson wrote:
>> On Mon, 31 Mar 2008, David Xu wrote:
>> 
>>> davidxu     2008-03-31 02:55:50 UTC
>>>
>>>  FreeBSD src repository
>>>
>>>  Modified files:
>>>    lib/libthr/thread    thr_cond.c thr_private.h thr_rwlock.c
>>>  Log:
>>>  Rewrite rwlock to user atomic operations to change rwlock state, this
>>>  eliminates internal mutex lock contention when most rwlock operations
>>>  are read.
>>>
>>>  Orignal patch provided by: jeff
>> 
>> Thanks David!
>> 
>> Do you still plan to do kernel side support so we can totally eliminate the 
>> pthread mutex and condvars from rwlock?  I have evidence that this would 
>> produce further improvements.
>> 
>> Jeff
>
> I have pure kernel version working, sometimes locking kernel sleep
> chain is more expensive than a pure userland mutex locking, since
> kernel sleep chain lock is global. I am hestiate adding more code
> to kernel since I have tested mysql super-smack and sysbench
> read-only and seen no visible performance differences.
> all patches are here:
>
> http://people.freebsd.org/~davidxu/patch/libthr_umtx_rwlock.diff
> http://people.freebsd.org/~davidxu/patch/umtx_rwlock.diff
>
> Te main bottleneck is in mysql itself, there are lots of lock
> contention, the following is a list of the main contention points when
> testing super-smack read benchmark.
>
> http://people.freebsd.org/~davidxu/mysql/mysql_lock.txt
>
> I don't think it scales beyond 4 cores ( I have tested it on a 4-core
> machine).

On linux it scales to 8 cores.  On FreeBSD CVS is limited by poor locking 
in the buffer cache.  I have a local hack so I can test changes to this. 
I will try my hack with your umtx changes and get back to you.

Thanks,
Jeff

>
> Regards,
> David Xu
>