From owner-freebsd-threads@FreeBSD.ORG Sat Apr 3 14:19:30 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0179E16A4DC for ; Sat, 3 Apr 2004 14:19:30 -0800 (PST) Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BEC743D31 for ; Sat, 3 Apr 2004 14:19:29 -0800 (PST) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-216-100-132-94.dsl.snfc21.pacbell.net [216.100.132.94])i33MJ9uO029528; Sat, 3 Apr 2004 17:19:09 -0500 Message-ID: <406F37F3.3050501@elischer.org> Date: Sat, 03 Apr 2004 14:17:23 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030524 X-Accept-Language: en, hu MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: threads@freebsd.org Subject: Re: PERFORCE change 50188 for review X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2004 22:19:30 -0000 Daniel Eischen wrote: > On Sat, 3 Apr 2004, Doug Rabson wrote: > > >>On Saturday 03 April 2004 19:22, Daniel Eischen wrote: >> >>>On Sat, 3 Apr 2004, Doug Rabson wrote: >>> >>>>I was just wandering around the internet looking at the scenery and >>>>I ended up here: >>>>http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86-64-Options.html. >>> >>>Neat. >>> >>> >>>>This document describes a new options (which is not supported by >>>>the compiler in current right now), -mno-tls-direct-seg-refs. This >>>>looks like it will do everything we need for both i386 and amd64, >>>>i.e. instead of code like: >>>> >>>> movl %gs:x@ntpoff, %eax >>>> >>>>it should generate: >>>> >>>> movl %gs:0, %eax >>>> movl x@ntpoff(%eax), %eax >>> >>>That's what I thought the SUN ABI was supposed to do, no? >>>Perhaps I should go back and read the TLS spec... >> >>The main difference, (for me anyway) is that the calling convention for >>tls_get_addr in the sun abi is a standard stack-based convention. This >>leads to bulky code sequences which are hard for the linker to >>transform when it realises that it can change a reference from e.g. >>global dynamic to local exec. > > > Oh, I was really only thinking that the tls_get_addr function > and everything else would be pretty much the same as the > GNU convention, except that there would be one extra > instruction for __thread references (like you show > above). I think this is what we were going on from the > start. > > >>>>Although I'm still not quite convinced that we can't do the first >>>>version with essentially zero cost for i386 at least. >>> >>>I think it might get messy trying to manage LDTs. Extra >>>locking will be needed when you need to borrow them from >>>other threads, and you need to make sure those other threads >>>aren't running and aren't scope system. You might as well >>>make a system call to continue the thread and let the >>>kernel do all the work. >> >>Probably. If we can arrange to reduce the syscall cost somewhat (e.g. >>with sysenter/sysexit instead of int $80), perhaps this still isn't too >>much of a problem. I think that most programs should do far fewer >>context switches than most other work. > > > But everything else being equal, it's so much easier > for the one extra instruction in the TLS reference. > Talking with Peter, it may be feasible to use the kernel to set %fs:0 to point to per-thread data as there is a very fast way to make syscalls (12 clocks vs 300 clocks, or so he says) so that leaves us only with problems on the x86. The option above is what I thought we were going to do all along for x86 -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v