From owner-freebsd-arch@freebsd.org Fri Dec 25 18:18:16 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E084AA51B1F; Fri, 25 Dec 2015 18:18:16 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL SHA256 CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AA862197E; Fri, 25 Dec 2015 18:18:16 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.15.1/8.15.1/NETPLEX) with ESMTP id tBPIIEvS003623; Fri, 25 Dec 2015 13:18:14 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Fri, 25 Dec 2015 13:18:14 -0500 (EST) Date: Fri, 25 Dec 2015 13:18:14 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net Reply-To: Daniel Eischen To: Konstantin Belousov cc: John Baldwin , freebsd-arch@freebsd.org, freebsd-threads@freebsd.org Subject: Re: libthr shared locks In-Reply-To: <20151224191408.GA3625@kib.kiev.ua> Message-ID: References: <20151223172528.GT3625@kib.kiev.ua> <4199356.DlQeWDh27F@ralph.baldwin.cx> <5496837.TbTQtANDNj@ralph.baldwin.cx> <20151224191408.GA3625@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Dec 2015 18:18:17 -0000 On Thu, 24 Dec 2015, Konstantin Belousov wrote: > On Thu, Dec 24, 2015 at 01:46:25PM -0500, Daniel Eischen wrote: >> Can we still implement things like robust and priority mutexes in a >> pshared mutex with Konstantin's implementation? The rest of the world >> (Linux, Solaris anyway) use structs and get by just fine ABI-wise. > > Yes, we do. I intend to do this as the next stage, planned the > implementation and did some preparations for it in the current patch. > This raises the question, why do you suppose that my approach with > the off-page would not allow it ? I am asking not to argument, but to > understand a possible shortcoming in the approach, which I missed. No, I was merely inquiring, if this is on your agenda, that's good. > From the implementation PoV, off-page is completely equivalent to the > in-line structs approach, and the difference is only in the initial > translation of say pthread_mutex_t to the structure (off-page lookup vs. > identity). The issues with maintaining the lists of the owned robust of > pi mutexes are same, and in fact you could see some non-trivial traces > of this in the _mutex_fork() reimplementation in my patch. > > Linux and Solaris get (large enough) structs early enough to avoid the ABI > issues. I remember Linux changing FILE layout in early days of glibc 2.0 > and resulting pain, while they already had the GNU symbol versioning > working and used. I guess the issue now is the apparent speedups without having the extra de-reference. 8-10% for things like mysql might be worth considering the userland structs. -- DE