Date: Tue, 30 Oct 2007 17:05:11 +0800 From: David Xu <davidxu@FreeBSD.org> To: Kris Kennaway <kris@FreeBSD.org> Cc: Daniel Eischen <deischen@FreeBSD.org>, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libthr/thread thr_mutex.c src/lib/libkse/thread thr_mutex.c src/include pthread.h Message-ID: <4726F3C7.2060506@freebsd.org> In-Reply-To: <4726EEFB.8030309@FreeBSD.org> References: <200710292101.l9TL1mAE049561@repoman.freebsd.org> <47268F17.1000106@freebsd.org> <Pine.GSO.4.64.0710292207140.19572@sea.ntplx.net> <47269AD0.3080906@freebsd.org> <4726EEFB.8030309@FreeBSD.org>
index | next in thread | previous in thread | raw e-mail
Kris Kennaway wrote: > David Xu wrote: > >> Daniel Eischen wrote: >> >>> On Tue, 30 Oct 2007, David Xu wrote: >>> >>>> I am not sure PTHREAD_MUTEX_ADAPTIVE_NP is a correct solution, in fact >>>> I think this is Linux crap, shouldn't PTHREAD_PRIO_PROTECT and >>>> PTHREAD_PRIO_INHERIT mutex be adaptivly spinned ? >>>> also this commit does not change mutex_self_lock() to handle the >>>> PTHREAD_MUTEX_ADAPTIVE_NP, what is the PTHREAD_MUTEX_ADAPTIVE_NP >>>> definition when the mutex is already locked by the currect thread ? >>>> deadlock or return error code ? >>> >>> >>> >>> I tend to agree with the "Linux crap" comment, but I hesitate >>> to use those words considering the recent sensor framework >>> incident ;-) >>> >> >> Isn't this commit an incident too ? :-) if it is not, then >> we should retire from FreeBSD now, as two thread library >> maintainers were bypassed. > > > Hi David, > > I'm honestly a bit surprised to hear that you consider yourself to be > the maintainer of this code, because while you have certainly worked > heavily on it in the past, I have sent several mails to you over the > past year or so raising various problems and ideas I have encountered in > the libthr and related code while working on performance tuning, and you > have declined to reply to many of them, or to participate in the ongoing > optimization work. > At least I am maintainer of libthr today unless I am replaced tommorrow. In fact, I am surpised to that this mutex type was added without public discussion, or even discussed with Dan. I did post a patch that said I was implementing spin mutex, as you can see, my last commit also has _sched_yield() loop, which may further helps performance. I did lots of work to improve mutex performance, for example I had code spinning in kernel for umtx but backed it out since I thought it is not mature. another is shared page idea, julian just said, in fact it is an old discussion with julian and jhb, you just don't know it. > That being said, it's only an "incident" if you choose to be offended by > the commit. > > I'd recommend instead focusing on the technical issues, specifically the > fact that there does not exist a better alternative way to do this at > the present date. I have discussed the reasons why in my previous > emails (in particular, an env variable is inappropriate), so please > refer to those specifc points in formulating any further reply. > > Jeff, Attilio and I have ideas about how we might be able to improve the > libthr and umtx code going forward, so we'd be delighted to have your > help in working on them. > > Kris > My last commit improves mysql select-smack benchmark on 4-core xeon from 48000 queries/s to 70000 queries/s, so my work is alternative way, I think adding new mutex type should be publically discussed rather than rushing into the source tree, since it adding new interfaces which have to be supported in future.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4726F3C7.2060506>