Date: Tue, 01 Apr 2008 10:18:49 +0800 From: David Xu <davidxu@FreeBSD.org> To: Jeff Roberson <jroberson@chesapeake.net> 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: <47F19B89.20601@freebsd.org> In-Reply-To: <20080331150346.R72156@desktop> References: <200803310255.m2V2toJl053104@repoman.freebsd.org> <20080331150346.R72156@desktop>
next in thread | previous in thread | raw e-mail | index | archive | help
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). Regards, David Xu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47F19B89.20601>