Date: Tue, 1 Apr 2008 01:39:55 -1000 (HST) From: Jeff Roberson <jroberson@chesapeake.net> To: David Xu <davidxu@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libthr/thread thr_cond.c thr_private.h thr_rwlock.c Message-ID: <20080401013919.M72156@desktop> In-Reply-To: <47F19B89.20601@freebsd.org> References: <200803310255.m2V2toJl053104@repoman.freebsd.org> <20080331150346.R72156@desktop> <47F19B89.20601@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080401013919.M72156>