Date: Sat, 3 Apr 2004 20:28:50 +0100 From: Doug Rabson <dfr@nlsystems.com> To: Daniel Eischen <eischen@vigrid.com> Cc: Julian Elischer <julian@elischer.org> Subject: Re: PERFORCE change 50188 for review Message-ID: <200404032028.50715.dfr@nlsystems.com> In-Reply-To: <Pine.GSO.4.10.10404031317370.28920-100000@pcnet5.pcnet.com> References: <Pine.GSO.4.10.10404031317370.28920-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 03 April 2004 19:22, Daniel Eischen wrote: > On Sat, 3 Apr 2004, Doug Rabson wrote: > > On Friday 02 April 2004 21:22, Daniel Eischen wrote: > > > On Fri, 2 Apr 2004, Julian Elischer wrote: > > > > The SUN API allows the destination of the %gs:0 to be changes > > > > at runtime by the user this allowing the UTS to switch threads > > > > "on the fly" without going back to the kernel. > > > > > > Yes, please, I don't see how the one extra indirection is > > > really going to affect much. This is where we intended to > > > go months ago (and years ago WRT KSE in general), and > > > everything has been designed around it. > > > > 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. > > > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200404032028.50715.dfr>