From owner-cvs-all@FreeBSD.ORG Tue Oct 30 09:04:20 2007 Return-Path: Delivered-To: cvs-all@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EEDF16A417; Tue, 30 Oct 2007 09:04:20 +0000 (UTC) (envelope-from davidxu@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8965E13C4E9; Tue, 30 Oct 2007 09:04:20 +0000 (UTC) (envelope-from davidxu@FreeBSD.org) Received: from [127.0.0.1] (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l9U94G1Z069962; Tue, 30 Oct 2007 09:04:18 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4726F3C7.2060506@freebsd.org> Date: Tue, 30 Oct 2007 17:05:11 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kris Kennaway References: <200710292101.l9TL1mAE049561@repoman.freebsd.org> <47268F17.1000106@freebsd.org> <47269AD0.3080906@freebsd.org> <4726EEFB.8030309@FreeBSD.org> In-Reply-To: <4726EEFB.8030309@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , 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 X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2007 09:04:20 -0000 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.