From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4714 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Transition path for removing lazy init of thread pointer Date: Mon, 24 Mar 2014 19:04:05 -0400 Message-ID: <20140324230405.GA23163@brightrain.aerifal.cx> References: <20140324174915.GA1263@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1395702252 30118 80.91.229.3 (24 Mar 2014 23:04:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 24 Mar 2014 23:04:12 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4718-gllmg-musl=m.gmane.org@lists.openwall.com Tue Mar 25 00:04:22 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WSDun-0003Ml-Vb for gllmg-musl@plane.gmane.org; Tue, 25 Mar 2014 00:04:22 +0100 Original-Received: (qmail 21529 invoked by uid 550); 24 Mar 2014 23:04:20 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 21515 invoked from network); 24 Mar 2014 23:04:19 -0000 Content-Disposition: inline In-Reply-To: <20140324174915.GA1263@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4714 Archived-At: On Mon, Mar 24, 2014 at 01:49:15PM -0400, Rich Felker wrote: > Phase 1: Initialize the thread pointer at startup, but do not make > anything in musl assume that the thread pointer is valid unless the > [...] Phase 1 is now complete. The intent is that it not break any usage (even on ancient kernels that are unsupported) that was not already broken before, so regression reports would be very appreciated if I'm wrong about that. At this point we now have two mandatory syscalls at startup on most archs (just one where setting the thread pointer is entirely a userspace operation). The second syscall is set_tid_address, and it seems like it should only be needed it pthread_create is being used (to that pthread_join will work), but it serves a second purpose of standing in for gettid() too. We could, however, eliminate it in some cases:x - In static-linked programs that never need to know their own tid and never create threads, it can be skipped. This could be achieved with some weak symbol magic. - Even in dynamic-linked programs, we could defer the tid lookup until it's needed by adding a __gettid() function/macro that looks in the thread structure, and if it finds zero, calls set_tid_address. This might add a few cycles to some synchronization primitives, but we're shaving a good number of cycles now anyway since lazy thread-pointer initialization is gone and we can inline the thread-pointer access in a lot more places. I'd welcome feedback on whether these sorts of optimizations (well, more like tradeoffs than outright optimizations) are desirable. Rich