From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4717 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 20:58:15 -0400 Message-ID: <20140325005815.GA23474@brightrain.aerifal.cx> References: <20140324174915.GA1263@brightrain.aerifal.cx> <20140324230405.GA23163@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 1395709100 20215 80.91.229.3 (25 Mar 2014 00:58:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Mar 2014 00:58:20 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4721-gllmg-musl=m.gmane.org@lists.openwall.com Tue Mar 25 01:58:30 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 1WSFhE-0005RF-Sf for gllmg-musl@plane.gmane.org; Tue, 25 Mar 2014 01:58:28 +0100 Original-Received: (qmail 14239 invoked by uid 550); 25 Mar 2014 00:58:28 -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 14231 invoked from network); 25 Mar 2014 00:58:27 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4717 Archived-At: On Mon, Mar 24, 2014 at 11:44:57PM +0000, Justin Cormack wrote: > On Mon, Mar 24, 2014 at 11:04 PM, Rich Felker wrote: > > > > 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 > > Which archs is it userspace only? Setting the thread pointer is a fully-userspace operation on microblaze, sh, and powerpc. On the rest it requires a syscall. Note that one negative side-effect of it being fully userspace is that we get no indication of whether the kernel is new enough to support threads properly (whereas normally, successful syscall to set the thread pointer means the kernel supports threads). So on these archs, pthread_create really needs to be doing some extra work to make sure threads are supported and the clone flags it's using will actually have an effect; otherwise it could end up creating threads that don't behave at all like threads... This is an issue we've ignored until now, but it's fairly minor, especially since microblaze didn't even exist during 2.4 and sh has been broken in the kernel up til now and until at least the next kernel release. > Any idea what the performance benefit of the optimisations might be? > Static linked non threaded programs sounds like a good target. Basically just cutting off one syscall that takes ~1000-3000 cycles that's always accompanied by a syscall that takes over 100000 cycles (execve). So not much, I think. Rich