Date: Sat, 3 Apr 2004 17:29:08 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: Julian Elischer <julian@elischer.org> Cc: threads@freebsd.org Subject: Re: PERFORCE change 50188 for review Message-ID: <Pine.GSO.4.10.10404031727180.24383-100000@pcnet5.pcnet.com> In-Reply-To: <406F37F3.3050501@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 3 Apr 2004, Julian Elischer wrote: > 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 Right, me too :-) -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10404031727180.24383-100000>