From owner-freebsd-threads@FreeBSD.ORG Sun Mar 28 06:47:37 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 C0F5816A4CE for ; Sun, 28 Mar 2004 06:47:37 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C27943D1D for ; Sun, 28 Mar 2004 06:47:37 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i2SElatf019814; Sun, 28 Mar 2004 09:47:36 -0500 (EST) Date: Sun, 28 Mar 2004 09:47:36 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Niall Douglas In-Reply-To: <406605CC.14911.CD2D006@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: GDB 6.0 and FreeBSD threads 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: Sun, 28 Mar 2004 14:47:37 -0000 On Sat, 27 Mar 2004, Niall Douglas wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > I'm nearly finished porting my project to FreeBSD from Linux but I'm > getting a SIGSEGV at odd places in the code. Unfortunately my project > absolutely requires G++ v3.4 as the template support in v3.3 is not > up to par. Hence one has a problem debugging the executable with gdb > <6.0 (it works, but it's flaky). > > I tried compiling gdb 6.0 on FreeBSD and it compiles fine. > Unfortunately it appears to be missing thread support which is most > annoying. After searching around, I've discovered you guys patched > gdb 5.x with uthread.c. > > Here's my question - how much work would be required to getting the > 5.x uthread.c to work with gdb 6.0? Has somebody already done most of > the work (if so, can you supply me with a diff)? I don't need > fantastic support, just enough to help me find this bug (it's weird - > it's almost as though g++ is writing off the end of the stack ie; bad > code generation. Yet surely if that were the case, we'd have the same > SIGSEGV on Linux :( ). Could be the threads have different stack sizes under FreeBSD. Try using a larger stack. No-one has touched uthread support for other GDB's as far as I know. Most work is going in to our other thread libraries. There is work trying to get GDB thread support for libpthread, and that should be here by 5.3-release. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sun Mar 28 15:06:07 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 61D6716A4CE for ; Sun, 28 Mar 2004 15:06:07 -0800 (PST) Received: from mail2.mail.iol.ie (mail2.mail.iol.ie [193.95.141.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 024EC43D1F for ; Sun, 28 Mar 2004 15:06:07 -0800 (PST) (envelope-from s_sourceforge@nedprod.com) Received: from dialup044.ts524.cwt.esat.net ([194.165.174.44] helo=kate) by mail2.mail.iol.ie with esmtp (Exim 3.36 #9) id 1B7jLw-0006PX-00 for freebsd-threads@freebsd.org; Mon, 29 Mar 2004 00:06:05 +0100 From: "Niall Douglas" To: freebsd-threads@freebsd.org Date: Mon, 29 Mar 2004 00:06:35 +0100 MIME-Version: 1.0 Message-ID: <4067688B.19545.1A50C1@localhost> Priority: normal In-reply-to: References: <406605CC.14911.CD2D006@localhost> X-PM-Encryptor: IDWPGP-PM32, 4 X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Subject: Re: GDB 6.0 and FreeBSD threads 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: Sun, 28 Mar 2004 23:06:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28 Mar 2004 at 9:47, Daniel Eischen wrote: > No-one has touched uthread support for other GDB's as > far as I know. Most work is going in to our other thread > libraries. There is work trying to get GDB thread support > for libpthread, and that should be here by 5.3-release. I discovered late last night that libc_r implements only userland threads which seem to have issues with pipes (my code kept hanging inside the pipe i/o). I then discovered there are real system scope threads too, but they're in a different library called libkse. You guys could seriously improve the documentation inside the man pages. Please! Just a two line paragraph would have saved me more than a day of work. After linking to libkse and finding it really doesn't like coexisting with libc_r, I discovered the libmap.conf trick and it works now. Unfortunately I'm back to square one in that no gdb supports kse threads. This is a major problem as my code is heavily multithreaded. Does this David Xu have some patch code for gdb around in some CVS repository? The only thing stopping me moving to FreeBSD as my primary Unix development platform is this as it's significantly faster than RedHat 9 on my system. If I could grab this support and get it mostly working, I could move to BSD permanently (in these last three days I find I prefer it to Linux for some unknown reason). Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBQGdafcEcvDLFGKbPEQKnXwCeOWRlCexwgIr0pryUtvJQgbkbG3wAoM9s k0gJ5q5O7bUdM7tELZY5sWxw =zYb3 -----END PGP SIGNATURE----- From owner-freebsd-threads@FreeBSD.ORG Sun Mar 28 21:15:02 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 3086416A4CE for ; Sun, 28 Mar 2004 21:15:02 -0800 (PST) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0343943D1F for ; Sun, 28 Mar 2004 21:15:01 -0800 (PST) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-216-100-132-94.dsl.snfc21.pacbell.net [216.100.132.94])i2T5EvGa216724; Mon, 29 Mar 2004 00:14:58 -0500 Message-ID: <4067B064.6090007@elischer.org> Date: Sun, 28 Mar 2004 21:13:08 -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: Niall Douglas References: <406605CC.14911.CD2D006@localhost> <4067688B.19545.1A50C1@localhost> In-Reply-To: <4067688B.19545.1A50C1@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: GDB 6.0 and FreeBSD threads 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: Mon, 29 Mar 2004 05:15:02 -0000 Niall Douglas wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 28 Mar 2004 at 9:47, Daniel Eischen wrote: > > >>No-one has touched uthread support for other GDB's as >>far as I know. Most work is going in to our other thread >>libraries. There is work trying to get GDB thread support >>for libpthread, and that should be here by 5.3-release. > > > I discovered late last night that libc_r implements only userland > threads which seem to have issues with pipes (my code kept hanging > inside the pipe i/o). I then discovered there are real system scope > threads too, but they're in a different library called libkse. actually it's now called libpthread and linkse was it's development name. We have't been exactly quiet about this.. it's even in the release notes for 5.2.1. > > You guys could seriously improve the documentation inside the man > pages. Please! Just a two line paragraph would have saved me more > than a day of work. > we can't guess what question every developer is going to ask.. But possibly the following paragraph in "man pthread" might be made a bit clearer... INSTALLATION The current FreeBSD POSIX thread implementation is built in three libraries, Reentrant C Library (libc_r, -lc_r), POSIX Threads Library (libpthread, -lpthread), and 1:1 Threading Library (libthr, -lthr). They contain both thread-safe versions of Standard C Library (libc, -lc) func- tions and the thread functions. Threaded applications are linked with one of these libraries. > After linking to libkse and finding it really doesn't like coexisting > with libc_r, I discovered the libmap.conf trick and it works now. > Unfortunately I'm back to square one in that no gdb supports kse > threads. This is a major problem as my code is heavily multithreaded. why is libc_r beinbg linked into your application? you need to select ONE of the libraries and link with that.. > > Does this David Xu have some patch code for gdb around in some CVS > repository? The only thing stopping me moving to FreeBSD as my > primary Unix development platform is this as it's significantly > faster than RedHat 9 on my system. If I could grab this support and > get it mostly working, I could move to BSD permanently (in these last > three days I find I prefer it to Linux for some unknown reason). The threads support package is at: http://people.freebsd.org/~davidxu/kse/thread_db/ however, realise that this is PRE_ALPHA. you are "on your own" except for direct corespondence with david. > > Cheers, > Niall > > > > > > -----BEGIN PGP SIGNATURE----- > Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 > > iQA/AwUBQGdafcEcvDLFGKbPEQKnXwCeOWRlCexwgIr0pryUtvJQgbkbG3wAoM9s > k0gJ5q5O7bUdM7tELZY5sWxw > =zYb3 > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" > -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v From owner-freebsd-threads@FreeBSD.ORG Sun Mar 28 22:13:55 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 AD2F416A4CE for ; Sun, 28 Mar 2004 22:13:55 -0800 (PST) Received: from mail2.mail.iol.ie (mail2.mail.iol.ie [193.95.141.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06FA743D1F for ; Sun, 28 Mar 2004 22:13:55 -0800 (PST) (envelope-from s_sourceforge@nedprod.com) Received: from dialup175.ts521.cwt.esat.net ([194.165.162.175] helo=kate) by mail2.mail.iol.ie with esmtp (Exim 3.36 #9) id 1B7q1l-00061g-00 for freebsd-threads@freebsd.org; Mon, 29 Mar 2004 07:13:42 +0100 From: "Niall Douglas" To: freebsd-threads@freebsd.org Date: Mon, 29 Mar 2004 07:13:31 +0100 MIME-Version: 1.0 Message-ID: <4067CC9B.8940.1A12F51@localhost> Priority: normal In-reply-to: <4067B064.6090007@elischer.org> References: <4067688B.19545.1A50C1@localhost> X-PM-Encryptor: IDWPGP-PM32, 4 X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Subject: Re: GDB 6.0 and FreeBSD threads 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: Mon, 29 Mar 2004 06:13:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28 Mar 2004 at 21:13, Julian Elischer wrote: > > I discovered late last night that libc_r implements only userland > > threads which seem to have issues with pipes (my code kept hanging > > inside the pipe i/o). I then discovered there are real system scope > > threads too, but they're in a different library called libkse. > > actually it's now called libpthread and linkse was it's development > name. We have't been exactly quiet about this.. it's even in the > release notes for 5.2.1. You must remember I've never been near FreeBSD before. When the man page says POSIX threads are supported, I assumed that meant a full implementation in libc_r as the man page specifies. You can see why I might think that, especially as libc_r doesn't complain when my code sets PTHREAD_SCOPE_SYSTEM which libc_r should return an error on by rights. BTW on my FreeBSD v5.2.1 the library is called libkse, not libpthread which doesn't exist. > > You guys could seriously improve the documentation inside the man > > pages. Please! Just a two line paragraph would have saved me more > > than a day of work. > > we can't guess what question every developer is going to ask.. > But possibly the following paragraph in "man pthread" > might be made a bit clearer... Typing man pthread on my FreeBSD v5.2.1 does not show the text you quoted. Instead it says it's in libc_r and mentions nothing else. > > After linking to libkse and finding it really doesn't like > > coexisting with libc_r, I discovered the libmap.conf trick and it > > works now. Unfortunately I'm back to square one in that no gdb > > supports kse threads. This is a major problem as my code is heavily > > multithreaded. > > why is libc_r beinbg linked into your application? > you need to select ONE of the libraries and link with that.. It's not me. I link against libGL and /it/ is linked against libc_r. > The threads support package is at: > > http://people.freebsd.org/~davidxu/kse/thread_db/ > however, realise that this is PRE_ALPHA. > you are "on your own" except for direct corespondence with david. Wicked. I had searched google for that in vain so thank you. Do I post bug reports here or to David directly? Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBQGe+jMEcvDLFGKbPEQIwLQCg21f2Enh3w+5aT3pRinHbFASZMS0AoIZn AJEBfwrkSJ/a3nm1BX7KJVh2 =ZqT3 -----END PGP SIGNATURE----- From owner-freebsd-threads@FreeBSD.ORG Sun Mar 28 23:43:51 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 7E01316A4CE for ; Sun, 28 Mar 2004 23:43:51 -0800 (PST) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02A6E43D49 for ; Sun, 28 Mar 2004 23:43:51 -0800 (PST) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-216-100-132-94.dsl.snfc21.pacbell.net [216.100.132.94])i2T7hmGa018434; Mon, 29 Mar 2004 02:43:49 -0500 Message-ID: <4067D344.8030403@elischer.org> Date: Sun, 28 Mar 2004 23:41:56 -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: Niall Douglas References: <4067688B.19545.1A50C1@localhost> <4067CC9B.8940.1A12F51@localhost> In-Reply-To: <4067CC9B.8940.1A12F51@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: GDB 6.0 and FreeBSD threads 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: Mon, 29 Mar 2004 07:43:51 -0000 Niall Douglas wrote: > -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > On 28 Mar 2004 at 21:13, Julian Elischer wrote: > > > > You must remember I've never been near FreeBSD before. When the man page says > POSIX threads are supported, I assumed that meant a full implementation in > libc_r as the man page specifies. You can see why I might think that, > especially as libc_r doesn't complain when my code sets PTHREAD_SCOPE_SYSTEM > which libc_r should return an error on by rights. On this topic, There are 3 separate compatible threads libraries Libc_r is only SCOPE_PROCESS, libpthreads implements SCOPE_PROCESS and SCOPE_SYSTEM, and libthr is only SCOPE_SYSTEM. Do you run ALL threads as scope system, or only some? We don't recommend COPE_SYSTEM unless it's really needed (for example to make some threads run at higher/lower priorities) as they are less efficient. Benchmark your app with both types. (I think Linux is only SCOPE_SYSTEM). > > BTW on my FreeBSD v5.2.1 the library is called libkse, not libpthread which > doesn't exist. > That's the problem with the fact that this field moving so quickly. You should probably upgrade to -current so that you can debug these threads. and get reeady for yur app to run on 5.3. > >>> You guys could seriously improve the documentation inside the man pages. >>> Please! Just a two line paragraph would have saved me more than a day of >>> work. >> >> we can't guess what question every developer is going to ask.. But possibly >> the following paragraph in "man pthread" might be made a bit clearer... > > > Typing man pthread on my FreeBSD v5.2.1 does not show the text you quoted. > Instead it says it's in libc_r and mentions nothing else. Hmm maybe it was added since.. oh well. At least you get to see that we are trying to cover the blank spots. > > >>> After linking to libkse and finding it really doesn't like coexisting >>> with libc_r, I discovered the libmap.conf trick and it works now. >>> Unfortunately I'm back to square one in that no gdb supports kse threads. >>> This is a major problem as my code is heavily multithreaded. >> >> why is libc_r beinbg linked into your application? you need to select ONE >> of the libraries and link with that.. > > > It's not me. I link against libGL and /it/ is linked against libc_r. warning: if you use the nvidia GL libraries you can not yet use libpthread. > > >> The threads support package is at: >> >> http://people.freebsd.org/~davidxu/kse/thread_db/ however, realise that >> this is PRE_ALPHA. you are "on your own" except for direct corespondence >> with david. > > > Wicked. I had searched google for that in vain so thank you. Do I post bug > reports here or to David directly? directly to david.. it's still in prerelease. Also, you MUST be running TODAY'S -current so you'll need to upgrade. Sorry but it's an area of active development. -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 05:06:51 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 0D6FE16A4CE for ; Mon, 29 Mar 2004 05:06:51 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF04D43D53 for ; Mon, 29 Mar 2004 05:06:50 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i2TD6ntf016980; Mon, 29 Mar 2004 08:06:49 -0500 (EST) Date: Mon, 29 Mar 2004 08:06:49 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Niall Douglas In-Reply-To: <4067688B.19545.1A50C1@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: GDB 6.0 and FreeBSD threads 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: Mon, 29 Mar 2004 13:06:51 -0000 On Mon, 29 Mar 2004, Niall Douglas wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 28 Mar 2004 at 9:47, Daniel Eischen wrote: > > > No-one has touched uthread support for other GDB's as > > far as I know. Most work is going in to our other thread > > libraries. There is work trying to get GDB thread support > > for libpthread, and that should be here by 5.3-release. > > I discovered late last night that libc_r implements only userland > threads which seem to have issues with pipes (my code kept hanging > inside the pipe i/o). I then discovered there are real system scope > threads too, but they're in a different library called libkse. > > You guys could seriously improve the documentation inside the man > pages. Please! Just a two line paragraph would have saved me more > than a day of work. > > After linking to libkse and finding it really doesn't like coexisting > with libc_r, I discovered the libmap.conf trick and it works now. > Unfortunately I'm back to square one in that no gdb supports kse > threads. This is a major problem as my code is heavily multithreaded. You'll probably have to wait for gdb support to hit the tree sometime before 5.3-release. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 05:12:26 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 A518F16A4CF for ; Mon, 29 Mar 2004 05:12:26 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4601343D4C for ; Mon, 29 Mar 2004 05:12:26 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i2TDCPtf018081; Mon, 29 Mar 2004 08:12:25 -0500 (EST) Date: Mon, 29 Mar 2004 08:12:25 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Niall Douglas In-Reply-To: <4067CC9B.8940.1A12F51@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: GDB 6.0 and FreeBSD threads 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: Mon, 29 Mar 2004 13:12:26 -0000 On Mon, 29 Mar 2004, Niall Douglas wrote: > > The threads support package is at: > > > > http://people.freebsd.org/~davidxu/kse/thread_db/ > > however, realise that this is PRE_ALPHA. > > you are "on your own" except for direct corespondence with david. > > Wicked. I had searched google for that in vain so thank you. Do I > post bug reports here or to David directly? Please don't try this; it is not for beginners with FreeBSD nor for folks not willing to stay with -current. For one thing, the patches change the thread mailbox format and this breaks ABI for threaded applications using libpthread. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 07:12:15 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 8500916A4CE for ; Mon, 29 Mar 2004 07:12:15 -0800 (PST) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4221743D2F for ; Mon, 29 Mar 2004 07:12:15 -0800 (PST) (envelope-from rodrigc@h00609772adf0.ne.client2.attbi.com) Received: from dibbler.crodrigues.org (h00609772adf0.ne.client2.attbi.com[66.31.45.197]) by comcast.net (rwcrmhc13) with ESMTP id <20040329151213015007ki9oe>; Mon, 29 Mar 2004 15:12:14 +0000 Received: from dibbler.crodrigues.org (localhost.crodrigues.org [127.0.0.1]) i2TFCLRM015141; Mon, 29 Mar 2004 10:12:22 -0500 (EST) (envelope-from rodrigc@h00609772adf0.ne.client2.attbi.com) Received: (from rodrigc@localhost) by dibbler.crodrigues.org (8.12.11/8.12.11/Submit) id i2TFCLBg015140; Mon, 29 Mar 2004 10:12:21 -0500 (EST) (envelope-from rodrigc) Date: Mon, 29 Mar 2004 10:12:21 -0500 From: Craig Rodrigues To: Julian Elischer Message-ID: <20040329151221.GA15088@crodrigues.org> References: <406605CC.14911.CD2D006@localhost> <4067688B.19545.1A50C1@localhost> <4067B064.6090007@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4067B064.6090007@elischer.org> User-Agent: Mutt/1.4.1i cc: freebsd-threads@freebsd.org Subject: Re: GDB 6.0 and FreeBSD threads 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: Mon, 29 Mar 2004 15:12:15 -0000 On Sun, Mar 28, 2004 at 09:13:08PM -0800, Julian Elischer wrote: > we can't guess what question every developer is going to ask.. > But possibly the following paragraph in "man pthread" > might be made a bit clearer... How about we add this to the pthread.3 man page, to be consistent with all the other pthread man pages? --- pthread.3.orig Mon Mar 29 09:57:00 2004 +++ pthread.3 Mon Mar 29 10:02:43 2004 @@ -36,6 +36,10 @@ .Sh NAME .Nm pthread .Nd POSIX thread functions +.Sh LIBRARY +.Lb libpthread +.Lb libthr +.Lb libc_r .Sh SYNOPSIS .In pthread.h .Sh DESCRIPTION -- Craig Rodrigues http://crodrigues.org rodrigc@crodrigues.org From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 09:16:43 2004 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D963516A4CE; Mon, 29 Mar 2004 09:16:43 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B976143D1F; Mon, 29 Mar 2004 09:16:43 -0800 (PST) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) i2THGhbv058837; Mon, 29 Mar 2004 09:16:43 -0800 (PST) (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i2THGh5c058833; Mon, 29 Mar 2004 09:16:43 -0800 (PST) (envelope-from linimon) Date: Mon, 29 Mar 2004 09:16:43 -0800 (PST) From: Mark Linimon Message-Id: <200403291716.i2THGh5c058833@freefall.freebsd.org> To: lars@koellers.net, linimon@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: kern/64313: FreeBSD (OpenBSD) pthread implicit set/unset O_NONBLOCK flag 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: Mon, 29 Mar 2004 17:16:44 -0000 Synopsis: FreeBSD (OpenBSD) pthread implicit set/unset O_NONBLOCK flag State-Changed-From-To: open->suspended State-Changed-By: linimon State-Changed-When: Mon Mar 29 09:15:36 PST 2004 State-Changed-Why: Incorporating text from misfiled followup kern/64349. http://www.freebsd.org/cgi/query-pr.cgi?pr=64313 From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 09:17:32 2004 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6BC0D16A4CE; Mon, 29 Mar 2004 09:17:32 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C30443D2D; Mon, 29 Mar 2004 09:17:32 -0800 (PST) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) i2THHWbv058899; Mon, 29 Mar 2004 09:17:32 -0800 (PST) (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i2THHW8Y058895; Mon, 29 Mar 2004 09:17:32 -0800 (PST) (envelope-from linimon) Date: Mon, 29 Mar 2004 09:17:32 -0800 (PST) From: Mark Linimon Message-Id: <200403291717.i2THHW8Y058895@freefall.freebsd.org> To: lars@koellers.net, linimon@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: kern/64313: FreeBSD (OpenBSD) pthread implicit set/unset O_NONBLOCK flag 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: Mon, 29 Mar 2004 17:17:32 -0000 Synopsis: FreeBSD (OpenBSD) pthread implicit set/unset O_NONBLOCK flag State-Changed-From-To: suspended->open State-Changed-By: linimon State-Changed-When: Mon Mar 29 09:16:56 PST 2004 State-Changed-Why: GNATS is one stupid program ... http://www.freebsd.org/cgi/query-pr.cgi?pr=64313 From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 09:19:01 2004 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93F4216A4CE; Mon, 29 Mar 2004 09:19:01 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7647B43D3F; Mon, 29 Mar 2004 09:19:01 -0800 (PST) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) i2THJ1bv058990; Mon, 29 Mar 2004 09:19:01 -0800 (PST) (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i2THJ1Ie058986; Mon, 29 Mar 2004 09:19:01 -0800 (PST) (envelope-from linimon) Date: Mon, 29 Mar 2004 09:19:01 -0800 (PST) From: Mark Linimon Message-Id: <200403291719.i2THJ1Ie058986@freefall.freebsd.org> To: lars@koellers.net, linimon@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: kern/64313: FreeBSD (OpenBSD) pthread implicit set/unset O_NONBLOCK flag 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: Mon, 29 Mar 2004 17:19:01 -0000 Synopsis: FreeBSD (OpenBSD) pthread implicit set/unset O_NONBLOCK flag State-Changed-From-To: open->suspended State-Changed-By: linimon State-Changed-When: Mon Mar 29 09:17:37 PST 2004 State-Changed-Why: Following the advice of respondants to this PR, mark this as suspended until and unless a volunteer is found who is willing to work on known libc_r issues. While this would be nice, it is unlikely, considering that 5.3 will probably mark the transition to 5-STABLE. http://www.freebsd.org/cgi/query-pr.cgi?pr=64313 From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 10:42:52 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 6486B16A4CF for ; Mon, 29 Mar 2004 10:42:52 -0800 (PST) Received: from rms04.rommon.net (rms04.rommon.net [212.54.2.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B1F743D3F for ; Mon, 29 Mar 2004 10:42:51 -0800 (PST) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (h81.vuokselantie10.fi [193.64.42.129]) by rms04.rommon.net (8.12.9p1/8.12.9) with ESMTP id i2TIgncM057658 for ; Mon, 29 Mar 2004 21:42:49 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <40686E29.1070801@he.iki.fi> Date: Mon, 29 Mar 2004 21:42:49 +0300 From: Petri Helenius User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-threads@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: thread syscalls 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: Mon, 29 Mar 2004 18:42:52 -0000 Are the thread syscalls expected to change again from 5.2 to 5.3 so statically linked binaries will break or are they expected to work alright? Is there a way to partially link binaries so libraries like libc and libkse would be dynamically linked but everything else would be contained with the executable? Pete From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 11:00:25 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 D89B316A4CF for ; Mon, 29 Mar 2004 11:00:25 -0800 (PST) Received: from herring.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2208243D1D for ; Mon, 29 Mar 2004 11:00:25 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from herring.rabson.org (herring.rabson.org [10.0.0.2]) by herring.rabson.org (8.12.11/8.12.11) with ESMTP id i2TJ0Etp011221 for ; Mon, 29 Mar 2004 20:00:14 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: freebsd-threads@freebsd.org Date: Mon, 29 Mar 2004 20:00:13 +0100 User-Agent: KMail/1.6.1 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200403292000.13794.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on herring.rabson.org X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' Subject: Thread Local Storage 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: Mon, 29 Mar 2004 19:00:26 -0000 I've been spending a bit of time recently familiarising myself with this TLS stuff and trying out a few things. I've been playing with rtld and I have a prototype patch which implements enough TLS support to let a non-threaded program which uses static TLS work. With a tiny bit more work I can have limited support for dynamic TLS as well (not for dlopen'ed modules yet though). Is there a p4 tree for this stuff yet? I'd like to check in what I have sometime. I've also been looking at libpthread and I can see some potential problems with it. Currently libpthread on i386 uses %gs to point at a struct kcb which seems to be a per-kse structure. This structure contains a pointer to a per-thread struct tcb and this pointer is managed by the userland context switch code. Other arches are similar, e.g. ia64 uses $tp to point at struct kcb. The problem with TLS is that the i386 ABI needs %gs to point at the TLS storage for the current thread (its a tiny bit more involved than that but that doesn't matter much for the purposed of this discussion). This leads to trouble since it looks like we will end up needing to allocate an LDT segment per thread, leading to an arbitrary limit on the number of threads (~8192). I can think of a couple of possible ways to get around this. One easy way would be to allocate a segment per KSE and call i386_set_ldt from the thread switch. Pretty ugly really and takes a syscall. Another slightly better way would be to lazy-allocate segments when we switch threads and reclaim segments from threads which haven't run recently. This technique would be able to get away with a smaller number of segments which tend to be owned by the threads which run most often. There is a similar issue with libthr but since it already allocates an LDT entry per thread there are no new limitations. Linux has an interesting wrinkle on the libthr solution - they have a GDT per cpu and they pre-allocate three GDT slots for TLS pointers (one for glibc, one for Wine and one spare). The kernel thread switching code fills in these GDT slots on the current cpu with values stored in the pcb-equivalent. From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 11:01:42 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 E6A4A16A4CE for ; Mon, 29 Mar 2004 11:01:42 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C843F43D2D for ; Mon, 29 Mar 2004 11:01:42 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) i2TJ1gbv083855 for ; Mon, 29 Mar 2004 11:01:42 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i2TJ1gh5083849 for freebsd-threads@freebsd.org; Mon, 29 Mar 2004 11:01:42 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 29 Mar 2004 11:01:42 -0800 (PST) Message-Id: <200403291901.i2TJ1gh5083849@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Subject: Current problem reports assigned to you 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: Mon, 29 Mar 2004 19:01:43 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/06/13] kern/19247 threads uthread_sigaction.c does not do anything s [2004/03/15] kern/64313 threads FreeBSD (OpenBSD) pthread implicit set/un 2 problems total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/07/18] kern/20016 threads pthreads: Cannot set scheduling timer/Can o [2000/08/26] misc/20861 threads libc_r does not honor socket timeouts o [2001/01/19] bin/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVT o [2001/01/25] bin/24632 threads libc_r delicate deviation from libc in ha o [2001/01/25] misc/24641 threads pthread_rwlock_rdlock can deadlock o [2001/11/26] bin/32295 threads pthread dont dequeue signals o [2002/02/01] i386/34536 threads accept() blocks other threads o [2002/05/25] kern/38549 threads the procces compiled whith pthread stoppe o [2002/06/27] bin/39922 threads [PATCH?] Threaded applications executed w o [2002/08/04] misc/41331 threads Pthread library open sets O_NONBLOCK flag o [2003/03/02] bin/48856 threads Setting SIGCHLD to SIG_IGN still leaves z o [2003/03/10] bin/49087 threads Signals lost in programs linked with libc a [2003/04/08] bin/50733 threads buildworld won't build, because of linkin o [2003/05/07] bin/51949 threads thread in accept cannot be cancelled 14 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/05/25] misc/18824 threads gethostbyname is not thread safe o [2000/10/21] misc/22190 threads A threaded read(2) from a socketpair(2) f o [2001/09/09] bin/30464 threads pthread mutex attributes -- pshared o [2002/05/02] bin/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwri s [2002/07/16] misc/40671 threads pthread_cancel doesn't remove thread from 5 problems total. From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 11:19:28 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 57B2816A4DB for ; Mon, 29 Mar 2004 11:19:28 -0800 (PST) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA3D143D39 for ; Mon, 29 Mar 2004 11:19:27 -0800 (PST) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-216-100-132-94.dsl.snfc21.pacbell.net [216.100.132.94])i2TJJPGa082354; Mon, 29 Mar 2004 14:19:26 -0500 Message-ID: <40687650.8060708@elischer.org> Date: Mon, 29 Mar 2004 11:17:36 -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: Petri Helenius References: <40686E29.1070801@he.iki.fi> In-Reply-To: <40686E29.1070801@he.iki.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: thread syscalls 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: Mon, 29 Mar 2004 19:19:28 -0000 Petri Helenius wrote: > > Are the thread syscalls expected to change again from 5.2 to 5.3 so > statically linked binaries will break or are they expected to work alright? There is a set of changes on teh way that are needed to allw gdb to debug threads. This will necessitate some new entries in the thread and upcall mailboxes. We may apply them relatively soon so hopefully you will be able to use thatas a base after which itwill probably not change too much. > > Is there a way to partially link binaries so libraries like libc and > libkse would be dynamically linked but everything else would be > contained with the executable? > I've seen it done.. I think you mention the .a libraries by name before the shared libraries. But it has been a long time.. > Pete > > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" > -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 11:27:03 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 380FD16A4CE for ; Mon, 29 Mar 2004 11:27:03 -0800 (PST) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4ADB43D2D for ; Mon, 29 Mar 2004 11:27:02 -0800 (PST) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-216-100-132-94.dsl.snfc21.pacbell.net [216.100.132.94])i2TJR0Ga191368; Mon, 29 Mar 2004 14:27:01 -0500 Message-ID: <40687814.70208@elischer.org> Date: Mon, 29 Mar 2004 11:25:08 -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: Doug Rabson References: <200403292000.13794.dfr@nlsystems.com> In-Reply-To: <200403292000.13794.dfr@nlsystems.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: Thread Local Storage 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: Mon, 29 Mar 2004 19:27:03 -0000 Doug Rabson wrote: > I've been spending a bit of time recently familiarising myself with this > TLS stuff and trying out a few things. I've been playing with rtld and > I have a prototype patch which implements enough TLS support to let a > non-threaded program which uses static TLS work. With a tiny bit more > work I can have limited support for dynamic TLS as well (not for > dlopen'ed modules yet though). Is there a p4 tree for this stuff yet? > I'd like to check in what I have sometime. there is a KSE p4 tree that is curently unused as we have everything in CVS at the moment.. > > I've also been looking at libpthread and I can see some potential > problems with it. Currently libpthread on i386 uses %gs to point at a > struct kcb which seems to be a per-kse structure. This structure > contains a pointer to a per-thread struct tcb and this pointer is > managed by the userland context switch code. Other arches are similar, > e.g. ia64 uses $tp to point at struct kcb. We're ahead of you there :-) In fact the spec requires that %gs:0 is the address of a POINTER to the per thread stuff.. The kse mailbox that %gs points to has reserved a field at this location to be that pointer. > > The problem with TLS is that the i386 ABI needs %gs to point at the TLS > storage for the current thread (its a tiny bit more involved than that > but that doesn't matter much for the purposed of this discussion). This > leads to trouble since it looks like we will end up needing to allocate > an LDT segment per thread, leading to an arbitrary limit on the number > of threads (~8192). No, you missed a level of indirection :-) (I did too originally). The x86 version of the spec (SUN variant) expects there to be a double indirection. ths allows the UTS to keep the pointer up to date as to which thread is running on that KSE. > > I can think of a couple of possible ways to get around this. One easy > way would be to allocate a segment per KSE and call i386_set_ldt from > the thread switch. Pretty ugly really and takes a syscall. Another > slightly better way would be to lazy-allocate segments when we switch > threads and reclaim segments from threads which haven't run recently. > This technique would be able to get away with a smaller number of > segments which tend to be owned by the threads which run most often. > > There is a similar issue with libthr but since it already allocates an > LDT entry per thread there are no new limitations. Linux has an > interesting wrinkle on the libthr solution - they have a GDT per cpu > and they pre-allocate three GDT slots for TLS pointers (one for glibc, > one for Wine and one spare). The kernel thread switching code fills in > these GDT slots on the current cpu with values stored in the > pcb-equivalent. Yes in fact we are looking at switching to something similar.. a GDT entry per CPU that the UTS plugs with "what I am running now" info for that CPU. > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" > -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 11:33:09 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 0C5F316A4CF for ; Mon, 29 Mar 2004 11:33:09 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77EC943D1D for ; Mon, 29 Mar 2004 11:33:08 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i2TJX7tf017821; Mon, 29 Mar 2004 14:33:07 -0500 (EST) Date: Mon, 29 Mar 2004 14:33:07 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Petri Helenius In-Reply-To: <40686E29.1070801@he.iki.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: thread syscalls 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: Mon, 29 Mar 2004 19:33:09 -0000 On Mon, 29 Mar 2004, Petri Helenius wrote: > > Are the thread syscalls expected to change again from 5.2 to 5.3 so > statically linked binaries will break or are they expected to work alright? Possibly. > Is there a way to partially link binaries so libraries like libc and > libkse would be dynamically linked but everything else would be > contained with the executable? Don't know. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 11:36:33 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 E494B16A4CE for ; Mon, 29 Mar 2004 11:36:33 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AB3643D4C for ; Mon, 29 Mar 2004 11:36:33 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i2TJaWtf018636; Mon, 29 Mar 2004 14:36:33 -0500 (EST) Date: Mon, 29 Mar 2004 14:36:32 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Doug Rabson In-Reply-To: <200403292000.13794.dfr@nlsystems.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: Thread Local Storage 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: Mon, 29 Mar 2004 19:36:34 -0000 On Mon, 29 Mar 2004, Doug Rabson wrote: > I've been spending a bit of time recently familiarising myself with this > TLS stuff and trying out a few things. I've been playing with rtld and > I have a prototype patch which implements enough TLS support to let a > non-threaded program which uses static TLS work. With a tiny bit more > work I can have limited support for dynamic TLS as well (not for > dlopen'ed modules yet though). Is there a p4 tree for this stuff yet? > I'd like to check in what I have sometime. > > I've also been looking at libpthread and I can see some potential > problems with it. Currently libpthread on i386 uses %gs to point at a > struct kcb which seems to be a per-kse structure. This structure > contains a pointer to a per-thread struct tcb and this pointer is > managed by the userland context switch code. Other arches are similar, > e.g. ia64 uses $tp to point at struct kcb. > > The problem with TLS is that the i386 ABI needs %gs to point at the TLS There are 2 different methods allowed for the i386 ABI. We want to use the other method in which there is an additional indirection. The current i386 libpthread stuff adheres to this method. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 11:39:40 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 A0A5016A4CE for ; Mon, 29 Mar 2004 11:39:40 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 694A043D1D for ; Mon, 29 Mar 2004 11:39:40 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (localhost [127.0.0.1]) by ns1.xcllnt.net (8.12.11/8.12.11) with ESMTP id i2TJde4Z052389; Mon, 29 Mar 2004 11:39:40 -0800 (PST) (envelope-from marcel@ns1.xcllnt.net) Received: (from marcel@localhost) by ns1.xcllnt.net (8.12.11/8.12.11/Submit) id i2TJdesW052388; Mon, 29 Mar 2004 11:39:40 -0800 (PST) (envelope-from marcel) Date: Mon, 29 Mar 2004 11:39:40 -0800 From: Marcel Moolenaar To: Doug Rabson Message-ID: <20040329193940.GA52335@ns1.xcllnt.net> References: <200403292000.13794.dfr@nlsystems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403292000.13794.dfr@nlsystems.com> User-Agent: Mutt/1.5.5.1i cc: freebsd-threads@freebsd.org Subject: Re: Thread Local Storage 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: Mon, 29 Mar 2004 19:39:40 -0000 On Mon, Mar 29, 2004 at 08:00:13PM +0100, Doug Rabson wrote: > > I've also been looking at libpthread and I can see some potential > problems with it. Currently libpthread on i386 uses %gs to point at a > struct kcb which seems to be a per-kse structure. This structure > contains a pointer to a per-thread struct tcb and this pointer is > managed by the userland context switch code. Other arches are similar, > e.g. ia64 uses $tp to point at struct kcb. On ia64, TP points to struct ia64_tp, which is the TLS. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 11:48:12 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 A745E16A4CE for ; Mon, 29 Mar 2004 11:48:12 -0800 (PST) Received: from mail1.mail.iol.ie (mail1.mail.iol.ie [193.120.142.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BF4A43D2D for ; Mon, 29 Mar 2004 11:48:12 -0800 (PST) (envelope-from s_sourceforge@nedprod.com) Received: from dialup202.ts521.cwt.esat.net ([194.165.162.202] helo=kate) by mail1.mail.iol.ie with esmtp (Exim 3.36 #9) id 1B82jq-0006Z0-00 for freebsd-threads@freebsd.org; Mon, 29 Mar 2004 20:48:06 +0100 From: "Niall Douglas" To: freebsd-threads@freebsd.org Date: Mon, 29 Mar 2004 20:48:00 +0100 MIME-Version: 1.0 Message-ID: <40688B80.18775.48ADA9C@localhost> Priority: normal In-reply-to: <4067D344.8030403@elischer.org> References: <4067CC9B.8940.1A12F51@localhost> X-PM-Encryptor: IDWPGP-PM32, 4 X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Subject: Re: GDB 6.0 and FreeBSD threads 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: Mon, 29 Mar 2004 19:48:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28 Mar 2004 at 23:41, Julian Elischer wrote: > On this topic, There are 3 separate compatible threads libraries > Libc_r is only SCOPE_PROCESS, libpthreads implements SCOPE_PROCESS and > SCOPE_SYSTEM, and libthr is only SCOPE_SYSTEM. Do you run ALL threads > as scope system, or only some? We don't recommend COPE_SYSTEM unless > it's really needed (for example to make some threads run at > higher/lower priorities) as they are less efficient. Benchmark your > app with both types. (I think Linux is only SCOPE_SYSTEM). The project also runs on Windows so up till now it's been assumed SCOPE_SYSTEM. That's too much for some of the threads so I'm very open to having some of them run as in-process threads. I had this in mind when designing the thread class, it's an easy extension. Here's a thought - surely on a M:N threading implementation the kernel and user side library can automatically optimise which threads don't need to be system scope? They could do this by maintaining a sleep & i/o history for each thread, noting when which threads run concurrently, which i/o dependencies exist between threads and from that dynamically rescope the thread plus perform dynamic priority boosting to minimise sleeps. Indeed, if the kernel scheduler felt it was being overtaxed, more threads could be moved in-process. To me there is little point investing in all the complexity of a M:N implementation if you don't implement such optimisation features - otherwise the substantial amounts of extra code cause things to run slower due to sheer binary size. Of course this subtly breaks POSIX compliance as you ignore what the application asks for - it also requires an inprocess scheduler which works identically to the kernel one, and currently libc_r doesn't do that. > > BTW on my FreeBSD v5.2.1 the library is called libkse, not > > libpthread which doesn't exist. > > That's the problem with the fact that this field moving so quickly. > You should probably upgrade to -current so that you can debug these > threads. and get reeady for yur app to run on 5.3. I had thought, perhaps foolishly, that since MacOS X has good threading support and it comes from FreeBSD then therefore FreeBSD must have mature threading support. You seem to have the functionality okay, just none of the tools quite yet. Writing threaded code is hard without a debugger! And for some strange reason, my sockets class hangs on FreeBSD when it works fine everywhere else. As all the blocking i/o in my project is done by threads, I have given up trying to debug it. > directly to david.. it's still in prerelease. > Also, you MUST be running TODAY'S -current so you'll need to upgrade. > Sorry but it's an area of active development. The roadmap says v5.3 beta will be out 1st March. I take it this has slipped? What precisely will be changing in v5.3? Is http://www.freebsd.org/releases/5.3R/todo.html and http://kerneltrap.org/node/view/1898 representative? Lastly, does the new scheduler give better performance on uniprocessor machines over the old one? I actually compiled it out for my kernel assuming a SMP kernel is slower on uniprocessor. Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBQGh9cMEcvDLFGKbPEQJvaQCeIPK72w6KBEyL1RrOHyiHI+RcMA4AoK5R VnHm2EdScFqAKFyXHfRZrphP =/gIb -----END PGP SIGNATURE----- From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 12:41:48 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 5E4E516A4CF for ; Mon, 29 Mar 2004 12:41:48 -0800 (PST) Received: from rms04.rommon.net (rms04.rommon.net [212.54.2.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 578D443D2D for ; Mon, 29 Mar 2004 12:41:47 -0800 (PST) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (h81.vuokselantie10.fi [193.64.42.129]) by rms04.rommon.net (8.12.9p1/8.12.9) with ESMTP id i2TKfjcM058011; Mon, 29 Mar 2004 23:41:45 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <40688A09.9070709@he.iki.fi> Date: Mon, 29 Mar 2004 23:41:45 +0300 From: Petri Helenius User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Niall Douglas References: <4067CC9B.8940.1A12F51@localhost> <40688B80.18775.48ADA9C@localhost> In-Reply-To: <40688B80.18775.48ADA9C@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit cc: freebsd-threads@freebsd.org Subject: Re: GDB 6.0 and FreeBSD threads 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: Mon, 29 Mar 2004 20:41:48 -0000 Niall Douglas wrote: >Here's a thought - surely on a M:N threading implementation the >kernel and user side library can automatically optimise which threads >don't need to be system scope? They could do this by maintaining a > > I would hate to see this happen. The added complexity and unpredictability would make implementations harder because you would have to account for an optimizer which tries to think what´s best for the crappy application/programmer who does not know what he wants. >sleep & i/o history for each thread, noting when which threads run >concurrently, which i/o dependencies exist between threads and from >that dynamically rescope the thread plus perform dynamic priority >boosting to minimise sleeps. Indeed, if the kernel scheduler felt it >was being overtaxed, more threads could be moved in-process. > > > Why not just run all threads SCOPE_PROCESS? Then the system will do that for you. >To me there is little point investing in all the complexity of a M:N >implementation if you don't implement such optimisation features - >otherwise the substantial amounts of extra code cause things to run >slower due to sheer binary size. Of course this subtly breaks POSIX > > The great advantage of process scope threads is the fact that you can hand over a mutex without going trough a process switch. Pete From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 13:16:29 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 BC5D616A4D5 for ; Mon, 29 Mar 2004 13:16:29 -0800 (PST) Received: from herring.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F79243D3F for ; Mon, 29 Mar 2004 13:16:29 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from herring.rabson.org (herring.rabson.org [10.0.0.2]) by herring.rabson.org (8.12.11/8.12.11) with ESMTP id i2TLGI8J011975; Mon, 29 Mar 2004 22:16:18 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Marcel Moolenaar Date: Mon, 29 Mar 2004 22:16:17 +0100 User-Agent: KMail/1.6.1 References: <200403292000.13794.dfr@nlsystems.com> <20040329193940.GA52335@ns1.xcllnt.net> In-Reply-To: <20040329193940.GA52335@ns1.xcllnt.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403292216.17819.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on herring.rabson.org X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: freebsd-threads@freebsd.org Subject: Re: Thread Local Storage 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: Mon, 29 Mar 2004 21:16:29 -0000 On Monday 29 March 2004 20:39, Marcel Moolenaar wrote: > On Mon, Mar 29, 2004 at 08:00:13PM +0100, Doug Rabson wrote: > > I've also been looking at libpthread and I can see some potential > > problems with it. Currently libpthread on i386 uses %gs to point at > > a struct kcb which seems to be a per-kse structure. This structure > > contains a pointer to a per-thread struct tcb and this pointer is > > managed by the userland context switch code. Other arches are > > similar, e.g. ia64 uses $tp to point at struct kcb. > > On ia64, TP points to struct ia64_tp, which is the TLS. Yes, I saw that. I had the mistaken impression that this was contained in the kcb but now I look at it again, it all seems fine. My real problems were with the i386 though. From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 13:19:54 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 0D35916A4CE for ; Mon, 29 Mar 2004 13:19:54 -0800 (PST) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1AAD43D1D for ; Mon, 29 Mar 2004 13:19:53 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc13) with ESMTP id <2004032921195101600i2inqe>; Mon, 29 Mar 2004 21:19:52 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA29962; Mon, 29 Mar 2004 13:28:44 -0800 (PST) Date: Mon, 29 Mar 2004 13:28:43 -0800 (PST) From: Julian Elischer To: Doug Rabson In-Reply-To: <200403292216.17819.dfr@nlsystems.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: Thread Local Storage 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: Mon, 29 Mar 2004 21:19:54 -0000 On Mon, 29 Mar 2004, Doug Rabson wrote: > On Monday 29 March 2004 20:39, Marcel Moolenaar wrote: > > On Mon, Mar 29, 2004 at 08:00:13PM +0100, Doug Rabson wrote: > > > I've also been looking at libpthread and I can see some potential > > > problems with it. Currently libpthread on i386 uses %gs to point at > > > a struct kcb which seems to be a per-kse structure. This structure > > > contains a pointer to a per-thread struct tcb and this pointer is > > > managed by the userland context switch code. Other arches are > > > similar, e.g. ia64 uses $tp to point at struct kcb. > > > > On ia64, TP points to struct ia64_tp, which is the TLS. > > Yes, I saw that. I had the mistaken impression that this was contained > in the kcb but now I look at it again, it all seems fine. My real > problems were with the i386 though. We had this doc in fromnt of us when we layed out the structures so they should be correct (at least for the "solaris variant". > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" > From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 13:21:02 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 9BAA716A4CE for ; Mon, 29 Mar 2004 13:21:02 -0800 (PST) Received: from herring.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8E1E43D31 for ; Mon, 29 Mar 2004 13:21:01 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from herring.rabson.org (herring.rabson.org [10.0.0.2]) by herring.rabson.org (8.12.11/8.12.11) with ESMTP id i2TLKEZW011994; Mon, 29 Mar 2004 22:20:14 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Julian Elischer Date: Mon, 29 Mar 2004 22:20:14 +0100 User-Agent: KMail/1.6.1 References: <200403292000.13794.dfr@nlsystems.com> <40687814.70208@elischer.org> In-Reply-To: <40687814.70208@elischer.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403292220.14081.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on herring.rabson.org X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: freebsd-threads@freebsd.org Subject: Re: Thread Local Storage 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: Mon, 29 Mar 2004 21:21:02 -0000 On Monday 29 March 2004 20:25, Julian Elischer wrote: > Doug Rabson wrote: > > I've been spending a bit of time recently familiarising myself with > > this TLS stuff and trying out a few things. I've been playing with > > rtld and I have a prototype patch which implements enough TLS > > support to let a non-threaded program which uses static TLS work. > > With a tiny bit more work I can have limited support for dynamic > > TLS as well (not for dlopen'ed modules yet though). Is there a p4 > > tree for this stuff yet? I'd like to check in what I have sometime. > > there is a KSE p4 tree that is curently unused as we have everything > in CVS at the moment.. > > > I've also been looking at libpthread and I can see some potential > > problems with it. Currently libpthread on i386 uses %gs to point at > > a struct kcb which seems to be a per-kse structure. This structure > > contains a pointer to a per-thread struct tcb and this pointer is > > managed by the userland context switch code. Other arches are > > similar, e.g. ia64 uses $tp to point at struct kcb. > > We're ahead of you there :-) > In fact the spec requires that %gs:0 is the address of a POINTER to > the per thread stuff.. The kse mailbox that %gs points to has > reserved a field at this location to be that pointer. > > > The problem with TLS is that the i386 ABI needs %gs to point at the > > TLS storage for the current thread (its a tiny bit more involved > > than that but that doesn't matter much for the purposed of this > > discussion). This leads to trouble since it looks like we will end > > up needing to allocate an LDT segment per thread, leading to an > > arbitrary limit on the number of threads (~8192). > > No, you missed a level of indirection :-) (I did too originally). > The x86 version of the spec (SUN variant) expects there to be a > double indirection. ths allows the UTS to keep the pointer up to date > as to which thread is running on that KSE. I saw that in the spec and that all seems fine. The problem I have is that using the GNU TLS model, %gs must also point at the next byte after the TLS storage with negative offsets from %gs accessing the storage (glibc gives the %gs segment a 4G size to allow this). In theory a static TLS access can reduce to just e.g.: movl %gs:x@ntpoff, %eax to read the value of 'int __thread x'. > > > I can think of a couple of possible ways to get around this. One > > easy way would be to allocate a segment per KSE and call > > i386_set_ldt from the thread switch. Pretty ugly really and takes a > > syscall. Another slightly better way would be to lazy-allocate > > segments when we switch threads and reclaim segments from threads > > which haven't run recently. This technique would be able to get > > away with a smaller number of segments which tend to be owned by > > the threads which run most often. > > > > There is a similar issue with libthr but since it already allocates > > an LDT entry per thread there are no new limitations. Linux has an > > interesting wrinkle on the libthr solution - they have a GDT per > > cpu and they pre-allocate three GDT slots for TLS pointers (one for > > glibc, one for Wine and one spare). The kernel thread switching > > code fills in these GDT slots on the current cpu with values stored > > in the pcb-equivalent. > > Yes in fact we are looking at switching to something similar.. > a GDT entry per CPU that the UTS plugs with "what I am running now" > info for that CPU. How do you do that without an expensive syscall? From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 13:21:12 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 A2CDA16A4CE for ; Mon, 29 Mar 2004 13:21:12 -0800 (PST) Received: from herring.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id B282143D1D for ; Mon, 29 Mar 2004 13:21:11 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from herring.rabson.org (herring.rabson.org [10.0.0.2]) by herring.rabson.org (8.12.11/8.12.11) with ESMTP id i2TLL06G012003; Mon, 29 Mar 2004 22:21:00 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Daniel Eischen Date: Mon, 29 Mar 2004 22:21:00 +0100 User-Agent: KMail/1.6.1 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403292221.00286.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on herring.rabson.org X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: freebsd-threads@freebsd.org Subject: Re: Thread Local Storage 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: Mon, 29 Mar 2004 21:21:12 -0000 On Monday 29 March 2004 20:36, Daniel Eischen wrote: > On Mon, 29 Mar 2004, Doug Rabson wrote: > > I've been spending a bit of time recently familiarising myself with > > this TLS stuff and trying out a few things. I've been playing with > > rtld and I have a prototype patch which implements enough TLS > > support to let a non-threaded program which uses static TLS work. > > With a tiny bit more work I can have limited support for dynamic > > TLS as well (not for dlopen'ed modules yet though). Is there a p4 > > tree for this stuff yet? I'd like to check in what I have sometime. > > > > I've also been looking at libpthread and I can see some potential > > problems with it. Currently libpthread on i386 uses %gs to point at > > a struct kcb which seems to be a per-kse structure. This structure > > contains a pointer to a per-thread struct tcb and this pointer is > > managed by the userland context switch code. Other arches are > > similar, e.g. ia64 uses $tp to point at struct kcb. > > > > The problem with TLS is that the i386 ABI needs %gs to point at the > > TLS > > There are 2 different methods allowed for the i386 ABI. > We want to use the other method in which there is an > additional indirection. The current i386 libpthread > stuff adheres to this method. Surely the GNU TLS ABI is preferable? It generates much smaller code and needs many fewer relocations. From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 13:26:12 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 C69BF16A4CE for ; Mon, 29 Mar 2004 13:26:12 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5905A43D41 for ; Mon, 29 Mar 2004 13:26:10 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i2TLQ7tf016191; Mon, 29 Mar 2004 16:26:07 -0500 (EST) Date: Mon, 29 Mar 2004 16:26:07 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Doug Rabson In-Reply-To: <200403292221.00286.dfr@nlsystems.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: Thread Local Storage 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: Mon, 29 Mar 2004 21:26:12 -0000 On Mon, 29 Mar 2004, Doug Rabson wrote: > On Monday 29 March 2004 20:36, Daniel Eischen wrote: > > On Mon, 29 Mar 2004, Doug Rabson wrote: > > > I've been spending a bit of time recently familiarising myself with > > > this TLS stuff and trying out a few things. I've been playing with > > > rtld and I have a prototype patch which implements enough TLS > > > support to let a non-threaded program which uses static TLS work. > > > With a tiny bit more work I can have limited support for dynamic > > > TLS as well (not for dlopen'ed modules yet though). Is there a p4 > > > tree for this stuff yet? I'd like to check in what I have sometime. > > > > > > I've also been looking at libpthread and I can see some potential > > > problems with it. Currently libpthread on i386 uses %gs to point at > > > a struct kcb which seems to be a per-kse structure. This structure > > > contains a pointer to a per-thread struct tcb and this pointer is > > > managed by the userland context switch code. Other arches are > > > similar, e.g. ia64 uses $tp to point at struct kcb. > > > > > > The problem with TLS is that the i386 ABI needs %gs to point at the > > > TLS > > > > There are 2 different methods allowed for the i386 ABI. > > We want to use the other method in which there is an > > additional indirection. The current i386 libpthread > > stuff adheres to this method. > > Surely the GNU TLS ABI is preferable? It generates much smaller code and > needs many fewer relocations. No, we don't want an LDT for every thread and don't want to force a syscall for a thread switch. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 13:41:21 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 41E8916A4DA for ; Mon, 29 Mar 2004 13:41:21 -0800 (PST) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DC8E43D48 for ; Mon, 29 Mar 2004 13:41:21 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc13) with ESMTP id <20040329214120015007jmuie>; Mon, 29 Mar 2004 21:41:20 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA30305; Mon, 29 Mar 2004 13:50:12 -0800 (PST) Date: Mon, 29 Mar 2004 13:50:11 -0800 (PST) From: Julian Elischer To: Doug Rabson In-Reply-To: <200403292220.14081.dfr@nlsystems.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: Thread Local Storage 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: Mon, 29 Mar 2004 21:41:21 -0000 On Mon, 29 Mar 2004, Doug Rabson wrote: > On Monday 29 March 2004 20:25, Julian Elischer wrote: > > Doug Rabson wrote: > > > I've been spending a bit of time recently familiarising myself with > > > this TLS stuff and trying out a few things. I've been playing with > > > rtld and I have a prototype patch which implements enough TLS > > > support to let a non-threaded program which uses static TLS work. > > > With a tiny bit more work I can have limited support for dynamic > > > TLS as well (not for dlopen'ed modules yet though). Is there a p4 > > > tree for this stuff yet? I'd like to check in what I have sometime. > > > > there is a KSE p4 tree that is curently unused as we have everything > > in CVS at the moment.. > > > > > I've also been looking at libpthread and I can see some potential > > > problems with it. Currently libpthread on i386 uses %gs to point at > > > a struct kcb which seems to be a per-kse structure. This structure > > > contains a pointer to a per-thread struct tcb and this pointer is > > > managed by the userland context switch code. Other arches are > > > similar, e.g. ia64 uses $tp to point at struct kcb. > > > > We're ahead of you there :-) > > In fact the spec requires that %gs:0 is the address of a POINTER to > > the per thread stuff.. The kse mailbox that %gs points to has > > reserved a field at this location to be that pointer. > > > > > The problem with TLS is that the i386 ABI needs %gs to point at the > > > TLS storage for the current thread (its a tiny bit more involved > > > than that but that doesn't matter much for the purposed of this > > > discussion). This leads to trouble since it looks like we will end > > > up needing to allocate an LDT segment per thread, leading to an > > > arbitrary limit on the number of threads (~8192). > > > > No, you missed a level of indirection :-) (I did too originally). > > The x86 version of the spec (SUN variant) expects there to be a > > double indirection. ths allows the UTS to keep the pointer up to date > > as to which thread is running on that KSE. > > I saw that in the spec and that all seems fine. The problem I have is > that using the GNU TLS model, %gs must also point at the next byte > after the TLS storage with negative offsets from %gs accessing the > storage (glibc gives the %gs segment a 4G size to allow this). In > theory a static TLS access can reduce to just e.g.: > > movl %gs:x@ntpoff, %eax > > to read the value of 'int __thread x'. yep.. unfortunatly we can't do this. weeeeellllll we MIGHT be able to do it but it would be messy for now we are going with the Solaris model. > > > > > > I can think of a couple of possible ways to get around this. One > > > easy way would be to allocate a segment per KSE and call > > > i386_set_ldt from the thread switch. Pretty ugly really and takes a > > > syscall. Another slightly better way would be to lazy-allocate > > > segments when we switch threads and reclaim segments from threads > > > which haven't run recently. This technique would be able to get > > > away with a smaller number of segments which tend to be owned by > > > the threads which run most often. > > > > > > There is a similar issue with libthr but since it already allocates > > > an LDT entry per thread there are no new limitations. Linux has an > > > interesting wrinkle on the libthr solution - they have a GDT per > > > cpu and they pre-allocate three GDT slots for TLS pointers (one for > > > glibc, one for Wine and one spare). The kernel thread switching > > > code fills in these GDT slots on the current cpu with values stored > > > in the pcb-equivalent. > > > > Yes in fact we are looking at switching to something similar.. > > a GDT entry per CPU that the UTS plugs with "what I am running now" > > info for that CPU. > > How do you do that without an expensive syscall? Each cpu has a GDT entry pointing to a slightly different location and the kernel and the UTS co-operate as to making the contents of that location keep track of the thread currently running. The kernel always makes sure that %gs points to the correct place when it goes back to userland and teh contents of that location is saved whenever a thread sleeps and is restored whenever it wakes up again. it can even be in kernel memory space as long as teh segment is defined as r/w to the user and the segment size is limitted to just that region it is allowed to read from. This actualy gives us a 'per thread' pointer rather than a per-kse pointer which might allow us to go to the GNU version of TLS but we haven't worked out the details.. David and peter have both looked at this but we haven't actually tried to do it yet.. From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 13:44:12 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 5EB9916A4CE; Mon, 29 Mar 2004 13:44:12 -0800 (PST) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 114C443D45; Mon, 29 Mar 2004 13:44:12 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc12) with ESMTP id <2004032921440901200ngklhe>; Mon, 29 Mar 2004 21:44:11 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA30331; Mon, 29 Mar 2004 13:53:03 -0800 (PST) Date: Mon, 29 Mar 2004 13:53:03 -0800 (PST) From: Julian Elischer To: Doug Rabson In-Reply-To: <200403292221.00286.dfr@nlsystems.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org cc: peter@freebsd.org Subject: Re: Thread Local Storage 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: Mon, 29 Mar 2004 21:44:12 -0000 On Mon, 29 Mar 2004, Doug Rabson wrote: > On Monday 29 March 2004 20:36, Daniel Eischen wrote: > > On Mon, 29 Mar 2004, Doug Rabson wrote: > > > I've been spending a bit of time recently familiarising myself with > > > this TLS stuff and trying out a few things. I've been playing with > > > rtld and I have a prototype patch which implements enough TLS > > > support to let a non-threaded program which uses static TLS work. > > > With a tiny bit more work I can have limited support for dynamic > > > TLS as well (not for dlopen'ed modules yet though). Is there a p4 > > > tree for this stuff yet? I'd like to check in what I have sometime. > > > > > > I've also been looking at libpthread and I can see some potential > > > problems with it. Currently libpthread on i386 uses %gs to point at > > > a struct kcb which seems to be a per-kse structure. This structure > > > contains a pointer to a per-thread struct tcb and this pointer is > > > managed by the userland context switch code. Other arches are > > > similar, e.g. ia64 uses $tp to point at struct kcb. > > > > > > The problem with TLS is that the i386 ABI needs %gs to point at the > > > TLS > > > > There are 2 different methods allowed for the i386 ABI. > > We want to use the other method in which there is an > > additional indirection. The current i386 libpthread > > stuff adheres to this method. > > Surely the GNU TLS ABI is preferable? It generates much smaller code and > needs many fewer relocations. We were working on teh "let's just get it going using the Solaris model which fits now, and then if we can use the GDT version of thread pointers we can possibly sim-lify it later.. the code is 'faster' for he GNU variant but it may not be significant in the performance of the average threaded program. From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 13:50:43 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 E714B16A4D0 for ; Mon, 29 Mar 2004 13:50:43 -0800 (PST) Received: from herring.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7EC3D43D45 for ; Mon, 29 Mar 2004 13:50:42 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from herring.rabson.org (herring.rabson.org [10.0.0.2]) by herring.rabson.org (8.12.11/8.12.11) with ESMTP id i2TLoVog012192; Mon, 29 Mar 2004 22:50:31 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Daniel Eischen Date: Mon, 29 Mar 2004 22:50:31 +0100 User-Agent: KMail/1.6.1 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403292250.31315.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on herring.rabson.org X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: freebsd-threads@freebsd.org Subject: Re: Thread Local Storage 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: Mon, 29 Mar 2004 21:50:44 -0000 On Monday 29 March 2004 22:26, Daniel Eischen wrote: > On Mon, 29 Mar 2004, Doug Rabson wrote: > > On Monday 29 March 2004 20:36, Daniel Eischen wrote: > > > On Mon, 29 Mar 2004, Doug Rabson wrote: > > > > I've been spending a bit of time recently familiarising myself > > > > with this TLS stuff and trying out a few things. I've been > > > > playing with rtld and I have a prototype patch which implements > > > > enough TLS support to let a non-threaded program which uses > > > > static TLS work. With a tiny bit more work I can have limited > > > > support for dynamic TLS as well (not for dlopen'ed modules yet > > > > though). Is there a p4 tree for this stuff yet? I'd like to > > > > check in what I have sometime. > > > > > > > > I've also been looking at libpthread and I can see some > > > > potential problems with it. Currently libpthread on i386 uses > > > > %gs to point at a struct kcb which seems to be a per-kse > > > > structure. This structure contains a pointer to a per-thread > > > > struct tcb and this pointer is managed by the userland context > > > > switch code. Other arches are similar, e.g. ia64 uses $tp to > > > > point at struct kcb. > > > > > > > > The problem with TLS is that the i386 ABI needs %gs to point at > > > > the TLS > > > > > > There are 2 different methods allowed for the i386 ABI. > > > We want to use the other method in which there is an > > > additional indirection. The current i386 libpthread > > > stuff adheres to this method. > > > > Surely the GNU TLS ABI is preferable? It generates much smaller > > code and needs many fewer relocations. > > No, we don't want an LDT for every thread and don't want > to force a syscall for a thread switch. But the code it generates is at least twice the size for dynamic TLS. It seems that the GNU people have done a better job defining the TLS abi for i386. You don't need a syscall at thread switch if you do something like: _thread_switch(...) { if (tcb doesn't have LDT entry) { if (!free LDT entries) steal LDT entry from non-running thread; allocate LDT entry and point it at TLS goop for tcb. } load_gs(tcb's LDT sel); ... } I just have this feeling that the GNU ABI is going to get far better testing and support in the future since thats what linux uses. From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 13:56:34 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 3E2FA16A4CE for ; Mon, 29 Mar 2004 13:56:34 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA90043D3F for ; Mon, 29 Mar 2004 13:56:33 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i2TLuXtf024354; Mon, 29 Mar 2004 16:56:33 -0500 (EST) Date: Mon, 29 Mar 2004 16:56:33 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Doug Rabson In-Reply-To: <200403292250.31315.dfr@nlsystems.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: Thread Local Storage 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: Mon, 29 Mar 2004 21:56:34 -0000 On Mon, 29 Mar 2004, Doug Rabson wrote: > On Monday 29 March 2004 22:26, Daniel Eischen wrote: > > On Mon, 29 Mar 2004, Doug Rabson wrote: > > > > > > Surely the GNU TLS ABI is preferable? It generates much smaller > > > code and needs many fewer relocations. > > > > No, we don't want an LDT for every thread and don't want > > to force a syscall for a thread switch. > > But the code it generates is at least twice the size for dynamic TLS. It > seems that the GNU people have done a better job defining the TLS abi > for i386. About the only thing that uses TLS that I know is nvidia's openGL. If you design an API correctly, there's no need for TLS. I would hope that it's usage would be limited. > You don't need a syscall at thread switch if you do something like: > > _thread_switch(...) > { > if (tcb doesn't have LDT entry) { > if (!free LDT entries) > steal LDT entry from non-running thread; > allocate LDT entry and point it at TLS goop for tcb. > } > load_gs(tcb's LDT sel); That's a system call on amd64. > ... > } > > I just have this feeling that the GNU ABI is going to get far better > testing and support in the future since thats what linux uses. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 13:57:57 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 8908C16A4CE for ; Mon, 29 Mar 2004 13:57:57 -0800 (PST) Received: from herring.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id E17C543D48 for ; Mon, 29 Mar 2004 13:57:56 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from herring.rabson.org (herring.rabson.org [10.0.0.2]) by herring.rabson.org (8.12.11/8.12.11) with ESMTP id i2TLvDYE012232; Mon, 29 Mar 2004 22:57:13 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Julian Elischer Date: Mon, 29 Mar 2004 22:57:13 +0100 User-Agent: KMail/1.6.1 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403292257.13481.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on herring.rabson.org X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: freebsd-threads@freebsd.org Subject: Re: Thread Local Storage 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: Mon, 29 Mar 2004 21:57:57 -0000 On Monday 29 March 2004 22:50, Julian Elischer wrote: > On Mon, 29 Mar 2004, Doug Rabson wrote: > > How do you do that without an expensive syscall? > > Each cpu has a GDT entry pointing to a slightly different location > and the kernel and the UTS co-operate as to making the contents of > that location keep track of the thread currently running. The kernel > always makes sure that %gs points to the correct place when it goes > back to userland and teh contents of that location is saved whenever > a thread sleeps and is restored whenever it wakes up again. > > it can even be in kernel memory space as long as teh segment > is defined as r/w to the user and the segment size is limitted to > just that region it is allowed to read from. > This actualy gives us a 'per thread' pointer rather than a per-kse > pointer which might allow us to go to the GNU version of TLS but we > haven't worked out the details.. > David and peter have both looked at this but we haven't actually > tried to do it yet.. Yes, I understand about the per-cpu GDT thing. I've been reading linux kernel code and glibc all afternoon and my brain is melting :-). It would work great for libthr. For the GNU TLS ABI, the %gs segment can't be in kernel space because of the negative offset thing which is generated by the local exec TLS model. That idiom requires the %gs segment to have a 4G limit so that the negative addresses can wrap round properly. If it wasn't for that single 'optimisation', we could just go with the GNU model right now. My question is, given that we are switching threads in userland, how can we get the right contents for the GDT without a syscall? From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 14:16:29 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 A8D0816A4CE for ; Mon, 29 Mar 2004 14:16:29 -0800 (PST) Received: from herring.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9ED643D3F for ; Mon, 29 Mar 2004 14:16:28 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from herring.rabson.org (herring.rabson.org [10.0.0.2]) by herring.rabson.org (8.12.11/8.12.11) with ESMTP id i2TMGHrR012354; Mon, 29 Mar 2004 23:16:17 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Daniel Eischen Date: Mon, 29 Mar 2004 23:16:17 +0100 User-Agent: KMail/1.6.1 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403292316.17288.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on herring.rabson.org X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: freebsd-threads@freebsd.org Subject: Re: Thread Local Storage 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: Mon, 29 Mar 2004 22:16:29 -0000 On Monday 29 March 2004 22:56, Daniel Eischen wrote: > On Mon, 29 Mar 2004, Doug Rabson wrote: > > On Monday 29 March 2004 22:26, Daniel Eischen wrote: > > > On Mon, 29 Mar 2004, Doug Rabson wrote: > > > > Surely the GNU TLS ABI is preferable? It generates much smaller > > > > code and needs many fewer relocations. > > > > > > No, we don't want an LDT for every thread and don't want > > > to force a syscall for a thread switch. > > > > But the code it generates is at least twice the size for dynamic > > TLS. It seems that the GNU people have done a better job defining > > the TLS abi for i386. > > About the only thing that uses TLS that I know is nvidia's > openGL. If you design an API correctly, there's no need > for TLS. I would hope that it's usage would be limited. I'd quite like to see us use it for stuff like errno, _res and other uglification currently in libc. Not until the 6.x timeframe though. > > > You don't need a syscall at thread switch if you do something like: > > > > _thread_switch(...) > > { > > if (tcb doesn't have LDT entry) { > > if (!free LDT entries) > > steal LDT entry from non-running thread; > > allocate LDT entry and point it at TLS goop for tcb. > > } > > load_gs(tcb's LDT sel); > > That's a system call on amd64. I'm not quite up to speed on amd64. So in 64-bit mode it doesn't really have an LDT at all, is that right? From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 14:27:57 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 D40A216A4CE for ; Mon, 29 Mar 2004 14:27:57 -0800 (PST) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A18043D1F for ; Mon, 29 Mar 2004 14:27:57 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc11) with ESMTP id <20040329222756011001m947e>; Mon, 29 Mar 2004 22:27:56 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA30871; Mon, 29 Mar 2004 14:36:50 -0800 (PST) Date: Mon, 29 Mar 2004 14:36:49 -0800 (PST) From: Julian Elischer To: Doug Rabson In-Reply-To: <200403292257.13481.dfr@nlsystems.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: Thread Local Storage 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: Mon, 29 Mar 2004 22:27:58 -0000 On Mon, 29 Mar 2004, Doug Rabson wrote: > On Monday 29 March 2004 22:50, Julian Elischer wrote: > > On Mon, 29 Mar 2004, Doug Rabson wrote: > > > How do you do that without an expensive syscall? > > > > Each cpu has a GDT entry pointing to a slightly different location > > and the kernel and the UTS co-operate as to making the contents of > > that location keep track of the thread currently running. The kernel > > always makes sure that %gs points to the correct place when it goes > > back to userland and teh contents of that location is saved whenever > > a thread sleeps and is restored whenever it wakes up again. > > > > it can even be in kernel memory space as long as teh segment > > is defined as r/w to the user and the segment size is limitted to > > just that region it is allowed to read from. > > This actualy gives us a 'per thread' pointer rather than a per-kse > > pointer which might allow us to go to the GNU version of TLS but we > > haven't worked out the details.. > > David and peter have both looked at this but we haven't actually > > tried to do it yet.. > > Yes, I understand about the per-cpu GDT thing. I've been reading linux > kernel code and glibc all afternoon and my brain is melting :-). It > would work great for libthr. > > For the GNU TLS ABI, the %gs segment can't be in kernel space because of > the negative offset thing which is generated by the local exec TLS > model. That idiom requires the %gs segment to have a 4G limit so that > the negative addresses can wrap round properly. If it wasn't for that > single 'optimisation', we could just go with the GNU model right now. and how do they stop the user from accessing kernel space then? > > My question is, given that we are switching threads in userland, how can > we get the right contents for the GDT without a syscall? > as you note, The thread library and the dynamic linker know ahead of time the size of the static area needed for each thread.. i.e. the size of the area addresed -vely. Unfortunatly you an only make use of this for N:N threads (I dislike teh term 1:1, which in my mind is a single threaded program) If you compile libpthread in 1:1 mode (define FORCE_SCOPE_SYSTEM when you compile it) then this would work for us but for M:N threads it woudl require a syscall for every context switch (which removes the whole point of M:N threads. The reason for M:N threads is the ability to hop between threads in userspace without doing a kernel entry. I tend to believe that going with the solaris model is good enough for now and that we can try optimise later if we think its worth while. We can use a 'simple per-CPU GDT %gs' and the solaris model and get enough for our purposes... lets just go with that.. amd64 and ia64 have their own challenges. From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 14:36:09 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 7DFBD16A4CE for ; Mon, 29 Mar 2004 14:36:09 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3AEC743D53 for ; Mon, 29 Mar 2004 14:36:09 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i2TMa8tf004570; Mon, 29 Mar 2004 17:36:08 -0500 (EST) Date: Mon, 29 Mar 2004 17:36:08 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Doug Rabson In-Reply-To: <200403292316.17288.dfr@nlsystems.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: Thread Local Storage 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: Mon, 29 Mar 2004 22:36:09 -0000 On Mon, 29 Mar 2004, Doug Rabson wrote: > On Monday 29 March 2004 22:56, Daniel Eischen wrote: > > On Mon, 29 Mar 2004, Doug Rabson wrote: > > > On Monday 29 March 2004 22:26, Daniel Eischen wrote: > > > > On Mon, 29 Mar 2004, Doug Rabson wrote: > > > > > Surely the GNU TLS ABI is preferable? It generates much smaller > > > > > code and needs many fewer relocations. > > > > > > > > No, we don't want an LDT for every thread and don't want > > > > to force a syscall for a thread switch. > > > > > > But the code it generates is at least twice the size for dynamic > > > TLS. It seems that the GNU people have done a better job defining > > > the TLS abi for i386. > > > > About the only thing that uses TLS that I know is nvidia's > > openGL. If you design an API correctly, there's no need > > for TLS. I would hope that it's usage would be limited. > > I'd quite like to see us use it for stuff like errno, _res and other > uglification currently in libc. Not until the 6.x timeframe though. I'd like to see libc free of TLS ;-) The _res stuff can be avoided by modifying the implementation to use thread-safe APIs. The current _res stuff can _almost_ be eliminated by passing using pthread_getspecific() once and passing the _res around internal APIs. That's actually a pretty simple change. > > > > > > You don't need a syscall at thread switch if you do something like: > > > > > > _thread_switch(...) > > > { > > > if (tcb doesn't have LDT entry) { > > > if (!free LDT entries) > > > steal LDT entry from non-running thread; > > > allocate LDT entry and point it at TLS goop for tcb. > > > } > > > load_gs(tcb's LDT sel); > > > > That's a system call on amd64. > > I'm not quite up to speed on amd64. So in 64-bit mode it doesn't really > have an LDT at all, is that right? I'm not sure, but you have to make a system call to set it or it's equivalent (amd64_set_fsbase()). -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 15:14: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 A5D1E16A4CE for ; Mon, 29 Mar 2004 15:14:30 -0800 (PST) Received: from daintree.corp.yahoo.com (daintree.corp.yahoo.com [216.145.52.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98D9D43D45 for ; Mon, 29 Mar 2004 15:14:30 -0800 (PST) (envelope-from peter@yahoo-inc.com) Received: by daintree.corp.yahoo.com (Postfix, from userid 2154) id 8D340881F; Mon, 29 Mar 2004 15:14:30 -0800 (PST) From: Peter Wemm To: freebsd-threads@freebsd.org Date: Mon, 29 Mar 2004 15:14:30 -0800 User-Agent: KMail/1.6.1 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403291514.30270.peter@wemm.org> cc: Julian Elischer Subject: Re: Thread Local Storage 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: Mon, 29 Mar 2004 23:14:30 -0000 On Monday 29 March 2004 02:36 pm, Julian Elischer wrote: > On Mon, 29 Mar 2004, Doug Rabson wrote: > > On Monday 29 March 2004 22:50, Julian Elischer wrote: > > > On Mon, 29 Mar 2004, Doug Rabson wrote: > > > > How do you do that without an expensive syscall? > > > > > > Each cpu has a GDT entry pointing to a slightly different > > > location and the kernel and the UTS co-operate as to making the > > > contents of that location keep track of the thread currently > > > running. The kernel always makes sure that %gs points to the > > > correct place when it goes back to userland and teh contents of > > > that location is saved whenever a thread sleeps and is restored > > > whenever it wakes up again. > > > > > > it can even be in kernel memory space as long as teh segment > > > is defined as r/w to the user and the segment size is limitted to > > > just that region it is allowed to read from. > > > This actualy gives us a 'per thread' pointer rather than a > > > per-kse pointer which might allow us to go to the GNU version of > > > TLS but we haven't worked out the details.. > > > David and peter have both looked at this but we haven't actually > > > tried to do it yet.. > > > > Yes, I understand about the per-cpu GDT thing. I've been reading > > linux kernel code and glibc all afternoon and my brain is melting > > :-). It would work great for libthr. > > > > For the GNU TLS ABI, the %gs segment can't be in kernel space > > because of the negative offset thing which is generated by the > > local exec TLS model. That idiom requires the %gs segment to have a > > 4G limit so that the negative addresses can wrap round properly. If > > it wasn't for that single 'optimisation', we could just go with the > > GNU model right now. > > and how do they stop the user from accessing kernel space then? They use page level protection and set *all* the segment limits to 4GB. This is actually an important optimization, because it causes P4 cpus to spend one less clock cycle generating addresses since t stops verifying the segment limits. Somebody tried this with the i386 kernel a few months ago. I dont recall the results. I doubt that it made a big difference though. Its probably something that only shows up on microbenchmarks. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 15:18:33 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 EBC6316A4D1 for ; Mon, 29 Mar 2004 15:18:33 -0800 (PST) Received: from daintree.corp.yahoo.com (daintree.corp.yahoo.com [216.145.52.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF5ED43D1F for ; Mon, 29 Mar 2004 15:18:33 -0800 (PST) (envelope-from peter@yahoo-inc.com) Received: by daintree.corp.yahoo.com (Postfix, from userid 2154) id D4D03881F; Mon, 29 Mar 2004 15:18:33 -0800 (PST) From: Peter Wemm To: freebsd-threads@freebsd.org Date: Mon, 29 Mar 2004 15:18:33 -0800 User-Agent: KMail/1.6.1 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403291518.33559.peter@wemm.org> Subject: Re: Thread Local Storage 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: Mon, 29 Mar 2004 23:18:34 -0000 On Monday 29 March 2004 02:36 pm, Daniel Eischen wrote: [..] > > > > You don't need a syscall at thread switch if you do something > > > > like: > > > > > > > > _thread_switch(...) > > > > { > > > > if (tcb doesn't have LDT entry) { > > > > if (!free LDT entries) > > > > steal LDT entry from non-running thread; > > > > allocate LDT entry and point it at TLS goop for tcb. > > > > } > > > > load_gs(tcb's LDT sel); > > > > > > That's a system call on amd64. > > > > I'm not quite up to speed on amd64. So in 64-bit mode it doesn't > > really have an LDT at all, is that right? > > I'm not sure, but you have to make a system call to set it > or it's equivalent (amd64_set_fsbase()). Correct. There are two ways to do these things on this cpu. One is to use descriptor tables. The catch is that using descriptor tables forces a 4GB limit. It won't wrap around. The other way is to write to the MSRs for fsbase/gsbase. But the downside of that is that is a priviliged operation and needs to be done in supervisor mode. I don't *have* an LDT on the amd64 kernel. I'm dreading having to emulate the i386 sysarch LDT stuff already. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 15:40:58 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 EEAC516A4CE for ; Mon, 29 Mar 2004 15:40:58 -0800 (PST) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 965D343D2D for ; Mon, 29 Mar 2004 15:40:58 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc12) with ESMTP id <2004032923405701200n82uqe>; Mon, 29 Mar 2004 23:40:57 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA31562; Mon, 29 Mar 2004 15:49:56 -0800 (PST) Date: Mon, 29 Mar 2004 15:49:54 -0800 (PST) From: Julian Elischer To: Peter Wemm In-Reply-To: <200403291518.33559.peter@wemm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: Thread Local Storage 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: Mon, 29 Mar 2004 23:40:59 -0000 On Mon, 29 Mar 2004, Peter Wemm wrote: > On Monday 29 March 2004 02:36 pm, Daniel Eischen wrote: > [..] > > > > > You don't need a syscall at thread switch if you do something > > > > > like: > > > > > > > > > > _thread_switch(...) > > > > > { > > > > > if (tcb doesn't have LDT entry) { > > > > > if (!free LDT entries) > > > > > steal LDT entry from non-running thread; > > > > > allocate LDT entry and point it at TLS goop for tcb. > > > > > } > > > > > load_gs(tcb's LDT sel); > > > > > > > > That's a system call on amd64. > > > > > > I'm not quite up to speed on amd64. So in 64-bit mode it doesn't > > > really have an LDT at all, is that right? > > > > I'm not sure, but you have to make a system call to set it > > or it's equivalent (amd64_set_fsbase()). > > Correct. There are two ways to do these things on this cpu. One is to > use descriptor tables. The catch is that using descriptor tables > forces a 4GB limit. It won't wrap around. The other way is to write > to the MSRs for fsbase/gsbase. But the downside of that is that is a > priviliged operation and needs to be done in supervisor mode. > > I don't *have* an LDT on the amd64 kernel. I'm dreading having to > emulate the i386 sysarch LDT stuff already. Hopefully we can migrate to the GDT idea.. > -- > Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com > "All of this is for nothing if we don't go to the stars" - JMS/B5 > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" > From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 18:36:41 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 6D4A416A4CE for ; Mon, 29 Mar 2004 18:36:41 -0800 (PST) Received: from mail1.mail.iol.ie (mail1.mail.iol.ie [193.120.142.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8C5E43D2D for ; Mon, 29 Mar 2004 18:36:40 -0800 (PST) (envelope-from s_sourceforge@nedprod.com) Received: from dialup326.ts522.cwt.esat.net ([194.165.169.70] helo=kate) by mail1.mail.iol.ie with esmtp (Exim 3.36 #9) id 1B897G-0006yR-00 for freebsd-threads@freebsd.org; Tue, 30 Mar 2004 03:36:39 +0100 From: "Niall Douglas" To: freebsd-threads@freebsd.org Date: Tue, 30 Mar 2004 02:24:09 +0100 MIME-Version: 1.0 Message-ID: <4068DA49.24401.5BE9BE4@localhost> Priority: normal In-reply-to: <40688A09.9070709@he.iki.fi> References: <40688B80.18775.48ADA9C@localhost> X-PM-Encryptor: IDWPGP-PM32, 4 X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT Content-description: Mail message body Subject: Re: GDB 6.0 and FreeBSD threads 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: Tue, 30 Mar 2004 02:36:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29 Mar 2004 at 23:41, Petri Helenius wrote: > >Here's a thought - surely on a M:N threading implementation the > >kernel and user side library can automatically optimise which threads > > don't need to be system scope? They could do this by maintaining a > > > I would hate to see this happen. The added complexity and > unpredictability would make implementations harder because you would > have to account for an optimizer which tries to think what´s best for > the crappy application/programmer who does not know what he wants. As I grow older, I believe that programmers should tell the computer what to do rather than how to do it. To tune the dependencies between threads waiting on each other is extremely tough, so tough most programmers don't bother. A 1:1 scheduler is usually written with the process side dumb as to what's happening in the scheduler so the kernel doesn't know about an impending i/o block or wait condition until it's traversed into kernel space. Basically what I'm suggesting is a form of spin lock for i/o points and greater devolvement of i/o operations out of the kernel. In something like the hurd this is supposed to be the whole point, but then that project has taken an age. I think we're really early into multithreading technology. We're very far from the perfect scheduler which could make multithreaded systems considerably faster than previous ones - there are user-land threaded i/o systems which gave Apache a massive speedup. An M:N system is clearly the future and we'll make mistakes in our first few attempts. However we'll get there eventually. > Why not just run all threads SCOPE_PROCESS? Then the system will do > that for you. The pthreads implementations I've seen won't utilise more than one processor unless it's SCOPE_SYSTEM. The obviates the reason most people use threads, hence the success of the 1:1 model which is a very blunt axe. > The great advantage of process scope threads is the fact that you can > hand over a mutex without going trough a process switch. I have a hand written mutex which avoids the kernel completely except to sleep and wake the thread. This process could also avoid the kernel as it's really a process-internal issue and my spin count code avoids that completely on low-contention locks. However, a thread context switch within the same process map is far less costly than a process context switch, even if it must enter the kernel - if this weren't so, all those diehard Unix fans wouldn't be having to face up to the death of the process forking model. Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBQGjMOcEcvDLFGKbPEQKMKACfZIoDBT+br69MgbW+sfgz9HANr0MAoKvn yldlx8YuekW9J9u4Gv6E54zU =LDUT -----END PGP SIGNATURE----- From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 18:53:37 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 67B9916A4CE for ; Mon, 29 Mar 2004 18:53:37 -0800 (PST) Received: from exchhz01.viatech.com.cn (ip-40-162-97-218.anlai.com [218.97.162.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id C58A743D3F for ; Mon, 29 Mar 2004 18:53:30 -0800 (PST) (envelope-from davidxu@freebsd.org) Received: from freebsd.org (DAVIDWNT [10.4.1.99]) by exchhz01.viatech.com.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HNTCCAPG; Tue, 30 Mar 2004 10:54:05 +0800 Message-ID: <4068E166.8050200@freebsd.org> Date: Tue, 30 Mar 2004 10:54:30 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Niall Douglas References: <40688B80.18775.48ADA9C@localhost> <4068DA49.24401.5BE9BE4@localhost> In-Reply-To: <4068DA49.24401.5BE9BE4@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit cc: freebsd-threads@freebsd.org Subject: Re: GDB 6.0 and FreeBSD threads 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: Tue, 30 Mar 2004 02:53:37 -0000 Niall Douglas wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On 29 Mar 2004 at 23:41, Petri Helenius wrote: > > > >>>Here's a thought - surely on a M:N threading implementation the >>>kernel and user side library can automatically optimise which threads >>>don't need to be system scope? They could do this by maintaining a >>> >>> >>> >>I would hate to see this happen. The added complexity and >>unpredictability would make implementations harder because you would >>have to account for an optimizer which tries to think what´s best for >>the crappy application/programmer who does not know what he wants. >> >> > >As I grow older, I believe that programmers should tell the computer >what to do rather than how to do it. To tune the dependencies between >threads waiting on each other is extremely tough, so tough most >programmers don't bother. A 1:1 scheduler is usually written with the >process side dumb as to what's happening in the scheduler so the >kernel doesn't know about an impending i/o block or wait condition >until it's traversed into kernel space. > >Basically what I'm suggesting is a form of spin lock for i/o points >and greater devolvement of i/o operations out of the kernel. In >something like the hurd this is supposed to be the whole point, but >then that project has taken an age. > >I think we're really early into multithreading technology. We're very >far from the perfect scheduler which could make multithreaded systems >considerably faster than previous ones - there are user-land threaded >i/o systems which gave Apache a massive speedup. An M:N system is >clearly the future and we'll make mistakes in our first few attempts. >However we'll get there eventually. > > > >>Why not just run all threads SCOPE_PROCESS? Then the system will do >>that for you. >> >> > >The pthreads implementations I've seen won't utilise more than one >processor unless it's SCOPE_SYSTEM. The obviates the reason most >people use threads, hence the success of the 1:1 model which is a >very blunt axe. > > > >>The great advantage of process scope threads is the fact that you can >>hand over a mutex without going trough a process switch. >> >> > >I have a hand written mutex which avoids the kernel completely except >to sleep and wake the thread. This process could also avoid the >kernel as it's really a process-internal issue and my spin count code >avoids that completely on low-contention locks. However, a thread >context switch within the same process map is far less costly than a >process context switch, even if it must enter the kernel - if this >weren't so, all those diehard Unix fans wouldn't be having to face up >to the death of the process forking model. > This is ideal case, in real world, a thread switch could cause a thread from other process be scheduled, this would cause CR3 on i386 to be reloaded for a new process, even when you are handing a pthread mutex off to a thread in same process. >Cheers, >Niall > > > > > >-----BEGIN PGP SIGNATURE----- >Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 > >iQA/AwUBQGjMOcEcvDLFGKbPEQKMKACfZIoDBT+br69MgbW+sfgz9HANr0MAoKvn >yldlx8YuekW9J9u4Gv6E54zU >=LDUT >-----END PGP SIGNATURE----- >_______________________________________________ >freebsd-threads@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-threads >To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" > > > > From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 19:38:01 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 5719516A4CE for ; Mon, 29 Mar 2004 19:38:01 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED86E43D1D for ; Mon, 29 Mar 2004 19:38:00 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i2U3c0tf017605; Mon, 29 Mar 2004 22:38:00 -0500 (EST) Date: Mon, 29 Mar 2004 22:38:00 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Niall Douglas In-Reply-To: <4068DA49.24401.5BE9BE4@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: GDB 6.0 and FreeBSD threads 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: Tue, 30 Mar 2004 03:38:01 -0000 On Tue, 30 Mar 2004, Niall Douglas wrote: > On 29 Mar 2004 at 23:41, Petri Helenius wrote: > > > Why not just run all threads SCOPE_PROCESS? Then the system will do > > that for you. > > The pthreads implementations I've seen won't utilise more than one > processor unless it's SCOPE_SYSTEM. The obviates the reason most > people use threads, hence the success of the 1:1 model which is a > very blunt axe. That's untrue for libpthread. It creates automatically creates one KSE for each CPU. You can increase the number of CPUs by setting sysctls kern.threads.debug=1 and raising kern.threads.virtual_cpu. It also respects pthread_setconcurrency, but you're limited to kern.threads.virtual_cpu. Yes, all process scope threads run in these KSES. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 20:40:51 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 6E5EC16A4CE for ; Mon, 29 Mar 2004 20:40:51 -0800 (PST) Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8F2343D39 for ; Mon, 29 Mar 2004 20:40:49 -0800 (PST) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-216-100-132-94.dsl.snfc21.pacbell.net [216.100.132.94])i2U4efQi235368; Mon, 29 Mar 2004 23:40:47 -0500 Message-ID: <4068F9D6.3070704@elischer.org> Date: Mon, 29 Mar 2004 20:38:46 -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: Niall Douglas References: <40688B80.18775.48ADA9C@localhost> <4068DA49.24401.5BE9BE4@localhost> In-Reply-To: <4068DA49.24401.5BE9BE4@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit cc: freebsd-threads@freebsd.org Subject: Re: GDB 6.0 and FreeBSD threads 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: Tue, 30 Mar 2004 04:40:51 -0000 Niall Douglas wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 29 Mar 2004 at 23:41, Petri Helenius wrote: > > >>>Here's a thought - surely on a M:N threading implementation the >>>kernel and user side library can automatically optimise which threads >>>don't need to be system scope? They could do this by maintaining a >>> >> >>I would hate to see this happen. The added complexity and >>unpredictability would make implementations harder because you would >>have to account for an optimizer which tries to think what´s best for >>the crappy application/programmer who does not know what he wants. > > > As I grow older, I believe that programmers should tell the computer > what to do rather than how to do it. To tune the dependencies between > threads waiting on each other is extremely tough, so tough most > programmers don't bother. A 1:1 scheduler is usually written with the > process side dumb as to what's happening in the scheduler so the > kernel doesn't know about an impending i/o block or wait condition > until it's traversed into kernel space. > > Basically what I'm suggesting is a form of spin lock for i/o points > and greater devolvement of i/o operations out of the kernel. In > something like the hurd this is supposed to be the whole point, but > then that project has taken an age. > > I think we're really early into multithreading technology. We're very > far from the perfect scheduler which could make multithreaded systems > considerably faster than previous ones - there are user-land threaded > i/o systems which gave Apache a massive speedup. An M:N system is > clearly the future and we'll make mistakes in our first few attempts. > However we'll get there eventually. > > >>Why not just run all threads SCOPE_PROCESS? Then the system will do >>that for you. > > > The pthreads implementations I've seen won't utilise more than one > processor unless it's SCOPE_SYSTEM. The obviates the reason most > people use threads, hence the success of the 1:1 model which is a > very blunt axe. Our definition of "process_scope" is that it runs with the weight of one process TIMES THE REQUESTED CONCURRANCY which is limmited to the number of CPUs. i.e. even in SCOPE PROCESS programs, teh default concurrancy is NCPU and we allow up to that number of threads to run at any one time, however we don't allow the process to use NTHREADS slots on the run queue. Only up to NCONCURANCY (which is limmitted to NCPU) of the threads are allowed to contend with other processes at any one time. The other threads can only contend with those threads to be one of teh lucky ones competing. The result is that teh process can have 100% ofthe cpu when there is no competition but if there is competition it has to compete on an "approximatly" equal footing with the other processes. (sure it's weight is amplified by NCPU but that is usually much less than NTHREADS). (there is also thread afffinity (not yet implemented) where a process that has excess quantum when it's running thread sleeps has first dibs on the remainder of it's quantum to use on other threads) > > >>The great advantage of process scope threads is the fact that you can >>hand over a mutex without going trough a process switch. > > > I have a hand written mutex which avoids the kernel completely except > to sleep and wake the thread. This process could also avoid the > kernel as it's really a process-internal issue and my spin count code > avoids that completely on low-contention locks. However, a thread > context switch within the same process map is far less costly than a > process context switch, even if it must enter the kernel - if this > weren't so, all those diehard Unix fans wouldn't be having to face up > to the death of the process forking model. Ah but Linux and Solaris have gone the other way.. They have abandonned M:N in favour of N:N with kernel based thread suspension. > > Cheers, -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 21:35:08 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 6462316A4CE for ; Mon, 29 Mar 2004 21:35:08 -0800 (PST) Received: from mail1.mail.iol.ie (mail1.mail.iol.ie [193.120.142.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id D61B143D41 for ; Mon, 29 Mar 2004 21:35:05 -0800 (PST) (envelope-from s_sourceforge@nedprod.com) Received: from dialup379.ts524.cwt.esat.net ([194.165.175.123] helo=kate) by mail1.mail.iol.ie with esmtp (Exim 3.36 #9) id 1B8Btv-00020t-00 for freebsd-threads@freebsd.org; Tue, 30 Mar 2004 06:35:04 +0100 From: "Niall Douglas" To: freebsd-threads@freebsd.org Date: Tue, 30 Mar 2004 06:26:12 +0100 MIME-Version: 1.0 Message-ID: <40691304.15123.69C3765@localhost> Priority: normal In-reply-to: References: <4068DA49.24401.5BE9BE4@localhost> X-PM-Encryptor: IDWPGP-PM32, 4 X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Subject: Re: GDB 6.0 and FreeBSD threads 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: Tue, 30 Mar 2004 05:35:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29 Mar 2004 at 22:38, Daniel Eischen wrote: > > > Why not just run all threads SCOPE_PROCESS? Then the system will > > > do that for you. > > > > The pthreads implementations I've seen won't utilise more than one > > processor unless it's SCOPE_SYSTEM. The obviates the reason most > > people use threads, hence the success of the 1:1 model which is a > > very blunt axe. > > That's untrue for libpthread. It creates automatically creates one > KSE for each CPU. You can increase the number of CPUs by setting > sysctls kern.threads.debug=1 and raising kern.threads.virtual_cpu. It > also respects pthread_setconcurrency, but you're limited to > kern.threads.virtual_cpu. Yes, all process scope threads run in these > KSES. My apologies if this is a question already answered many times previously - what's then the difference between specifying SCOPE_SYSTEM and SCOPE_PROCESS on libpthread? Is it basically whether the thread competes with all threads or just with threads within its process for that process' time slice? Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBQGkE9MEcvDLFGKbPEQJZawCfRWCdhRQsGw9w68NA1UvhmjEQPm8AoOG+ JCTA4487OHDzXKt792tbC6q5 =cabR -----END PGP SIGNATURE----- From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 21:35:10 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 80B9C16A4CE for ; Mon, 29 Mar 2004 21:35:10 -0800 (PST) Received: from mail1.mail.iol.ie (mail1.mail.iol.ie [193.120.142.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4423443D46 for ; Mon, 29 Mar 2004 21:35:10 -0800 (PST) (envelope-from s_sourceforge@nedprod.com) Received: from dialup379.ts524.cwt.esat.net ([194.165.175.123] helo=kate) by mail1.mail.iol.ie with esmtp (Exim 3.36 #9) id 1B8Bty-00020t-00 for freebsd-threads@freebsd.org; Tue, 30 Mar 2004 06:35:07 +0100 From: "Niall Douglas" To: freebsd-threads@freebsd.org Date: Tue, 30 Mar 2004 06:35:34 +0100 MIME-Version: 1.0 Message-ID: <40691536.2959.6A4C95E@localhost> Priority: normal In-reply-to: <4068F9D6.3070704@elischer.org> References: <4068DA49.24401.5BE9BE4@localhost> X-PM-Encryptor: IDWPGP-PM32, 4 X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Subject: Re: GDB 6.0 and FreeBSD threads 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: Tue, 30 Mar 2004 05:35:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29 Mar 2004 at 20:38, Julian Elischer wrote: > Ah but Linux and Solaris have gone the other way.. > They have abandonned M:N in favour of N:N with kernel based thread > suspension. I haven't implemented a thread scheduler in some years, but I am more familiar with what's required than many who state an opinion on M:N vs. 1:1. My instinct says that M:N is the superior solution - I don't have anything to prove this and certainly it'll be tricky, but generally anything which increases parallelisability will increase scalability. I had been watching your work from afar just out of interest in how you do with a real M:N implementation. Someone asked for my library to work on FreeBSD, so now I'm actually part of the process. I look forward to it. Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBQGkHJsEcvDLFGKbPEQK2dQCePDAlbbO0nW1izrS38nByHSqxZX8An1uz fdEpkLzqfDuPzS2eMu01vw10 =aVNt -----END PGP SIGNATURE----- From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 22:07:40 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 4061916A4CE for ; Mon, 29 Mar 2004 22:07:40 -0800 (PST) Received: from rms04.rommon.net (rms04.rommon.net [212.54.2.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2415643D31 for ; Mon, 29 Mar 2004 22:07:39 -0800 (PST) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (h81.vuokselantie10.fi [193.64.42.129]) by rms04.rommon.net (8.12.9p1/8.12.9) with ESMTP id i2U67acM059783; Tue, 30 Mar 2004 09:07:37 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <40690EA8.5050908@he.iki.fi> Date: Tue, 30 Mar 2004 09:07:36 +0300 From: Petri Helenius User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Niall Douglas References: <4068DA49.24401.5BE9BE4@localhost> <40691304.15123.69C3765@localhost> In-Reply-To: <40691304.15123.69C3765@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit cc: freebsd-threads@freebsd.org Subject: Re: GDB 6.0 and FreeBSD threads 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: Tue, 30 Mar 2004 06:07:40 -0000 Niall Douglas wrote: > >My apologies if this is a question already answered many times >previously - what's then the difference between specifying >SCOPE_SYSTEM and SCOPE_PROCESS on libpthread? Is it basically whether >the thread competes with all threads or just with threads within its >process for that process' time slice? > > > SCOPE_SYSTEM threads get their own kse while SCOPE_PROCESS threads share number of kse´s defined by kern.threads.virtual_cpu or concurrency. Pete From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 22:25:36 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 1B54716A4CE for ; Mon, 29 Mar 2004 22:25:36 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD05F43D54 for ; Mon, 29 Mar 2004 22:25:35 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i2U6PZtf028635; Tue, 30 Mar 2004 01:25:35 -0500 (EST) Date: Tue, 30 Mar 2004 01:25:35 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Niall Douglas In-Reply-To: <40691304.15123.69C3765@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: GDB 6.0 and FreeBSD threads 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: Tue, 30 Mar 2004 06:25:36 -0000 On Tue, 30 Mar 2004, Niall Douglas wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 29 Mar 2004 at 22:38, Daniel Eischen wrote: > > > > > Why not just run all threads SCOPE_PROCESS? Then the system will > > > > do that for you. > > > > > > The pthreads implementations I've seen won't utilise more than one > > > processor unless it's SCOPE_SYSTEM. The obviates the reason most > > > people use threads, hence the success of the 1:1 model which is a > > > very blunt axe. > > > > That's untrue for libpthread. It creates automatically creates one > > KSE for each CPU. You can increase the number of CPUs by setting > > sysctls kern.threads.debug=1 and raising kern.threads.virtual_cpu. It > > also respects pthread_setconcurrency, but you're limited to > > kern.threads.virtual_cpu. Yes, all process scope threads run in these > > KSES. > > My apologies if this is a question already answered many times > previously - what's then the difference between specifying > SCOPE_SYSTEM and SCOPE_PROCESS on libpthread? Is it basically whether > the thread competes with all threads or just with threads within its > process for that process' time slice? It is exactly what POSIX says it should be. All system scope threads in the system compete against each for CPU time. For process scope threads, they use the process quantum (perhaps multiplied by NCPU). System scope threads get their own quantum and are inherintly unfair in that they give their process more CPU time. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 23:30:26 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 3400A16A4CE for ; Mon, 29 Mar 2004 23:30:26 -0800 (PST) Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id DABA443D46 for ; Mon, 29 Mar 2004 23:30:25 -0800 (PST) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-216-100-132-94.dsl.snfc21.pacbell.net [216.100.132.94])i2U7UNTa173086; Tue, 30 Mar 2004 02:30:24 -0500 Message-ID: <406921A2.7020701@elischer.org> Date: Mon, 29 Mar 2004 23:28:34 -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: Petri Helenius References: <4068DA49.24401.5BE9BE4@localhost> <40691304.15123.69C3765@localhost> <40690EA8.5050908@he.iki.fi> In-Reply-To: <40690EA8.5050908@he.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit cc: freebsd-threads@freebsd.org Subject: Re: GDB 6.0 and FreeBSD threads 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: Tue, 30 Mar 2004 07:30:26 -0000 Petri Helenius wrote: > Niall Douglas wrote: > >> >> My apologies if this is a question already answered many times >> previously - what's then the difference between specifying >> SCOPE_SYSTEM and SCOPE_PROCESS on libpthread? Is it basically whether >> the thread competes with all threads or just with threads within its >> process for that process' time slice? pretty much.. >> >> >> > SCOPE_SYSTEM threads get their own kse while SCOPE_PROCESS threads share > number of kse´s defined by kern.threads.virtual_cpu or concurrency. where "KSE" stands for "Kernel Schedulable Entity" -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v From owner-freebsd-threads@FreeBSD.ORG Tue Mar 30 00:25:15 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 6775516A4CE for ; Tue, 30 Mar 2004 00:25:15 -0800 (PST) Received: from herring.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B05643D2F for ; Tue, 30 Mar 2004 00:25:14 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from herring.rabson.org (herring.rabson.org [10.0.0.2]) by herring.rabson.org (8.12.11/8.12.11) with ESMTP id i2U8P2Ti015770; Tue, 30 Mar 2004 09:25:03 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Peter Wemm Date: Tue, 30 Mar 2004 09:25:02 +0100 User-Agent: KMail/1.6.1 References: <200403291518.33559.peter@wemm.org> In-Reply-To: <200403291518.33559.peter@wemm.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403300925.02485.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on herring.rabson.org X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: freebsd-threads@freebsd.org Subject: Re: Thread Local Storage 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: Tue, 30 Mar 2004 08:25:15 -0000 On Tuesday 30 March 2004 00:18, Peter Wemm wrote: > On Monday 29 March 2004 02:36 pm, Daniel Eischen wrote: > [..] > > > > > > You don't need a syscall at thread switch if you do something > > > > > like: > > > > > > > > > > _thread_switch(...) > > > > > { > > > > > if (tcb doesn't have LDT entry) { > > > > > if (!free LDT entries) > > > > > steal LDT entry from non-running thread; > > > > > allocate LDT entry and point it at TLS goop for tcb. > > > > > } > > > > > load_gs(tcb's LDT sel); > > > > > > > > That's a system call on amd64. > > > > > > I'm not quite up to speed on amd64. So in 64-bit mode it doesn't > > > really have an LDT at all, is that right? > > > > I'm not sure, but you have to make a system call to set it > > or it's equivalent (amd64_set_fsbase()). > > Correct. There are two ways to do these things on this cpu. One is > to use descriptor tables. The catch is that using descriptor tables > forces a 4GB limit. It won't wrap around. The other way is to write > to the MSRs for fsbase/gsbase. But the downside of that is that is a > priviliged operation and needs to be done in supervisor mode. What do you put in %fs and %gs for the non-table mode? The TLS ABI for amd64 is a 64bit equivalent to the GNU i386 ABI (with %fs instead of %gs). It also allows stuff like 'movq %fs:x@tpoff, %rax' where x@tpoff resolves to the negative offset from the end of the TLS block to the location of x. I can't see any way of avoiding setting fsbase on thread switch here. > > I don't *have* an LDT on the amd64 kernel. I'm dreading having to > emulate the i386 sysarch LDT stuff already. Segment registers. Not the worlds greatest idea... From owner-freebsd-threads@FreeBSD.ORG Tue Mar 30 00:36:02 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 50EA616A4CF for ; Tue, 30 Mar 2004 00:36:02 -0800 (PST) Received: from herring.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94D8643D2F for ; Tue, 30 Mar 2004 00:36:01 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from herring.rabson.org (herring.rabson.org [10.0.0.2]) by herring.rabson.org (8.12.11/8.12.11) with ESMTP id i2U8ZoMg015838; Tue, 30 Mar 2004 09:35:50 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Daniel Eischen Date: Tue, 30 Mar 2004 09:35:49 +0100 User-Agent: KMail/1.6.1 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403300935.49999.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on herring.rabson.org X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: freebsd-threads@freebsd.org Subject: Re: Thread Local Storage 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: Tue, 30 Mar 2004 08:36:02 -0000 On Monday 29 March 2004 23:36, Daniel Eischen wrote: > On Mon, 29 Mar 2004, Doug Rabson wrote: > > On Monday 29 March 2004 22:56, Daniel Eischen wrote: > > > On Mon, 29 Mar 2004, Doug Rabson wrote: > > > > On Monday 29 March 2004 22:26, Daniel Eischen wrote: > > > > > On Mon, 29 Mar 2004, Doug Rabson wrote: > > > > > > Surely the GNU TLS ABI is preferable? It generates much > > > > > > smaller code and needs many fewer relocations. > > > > > > > > > > No, we don't want an LDT for every thread and don't want > > > > > to force a syscall for a thread switch. > > > > > > > > But the code it generates is at least twice the size for > > > > dynamic TLS. It seems that the GNU people have done a better > > > > job defining the TLS abi for i386. > > > > > > About the only thing that uses TLS that I know is nvidia's > > > openGL. If you design an API correctly, there's no need > > > for TLS. I would hope that it's usage would be limited. > > > > I'd quite like to see us use it for stuff like errno, _res and > > other uglification currently in libc. Not until the 6.x timeframe > > though. > > I'd like to see libc free of TLS ;-) The _res stuff can be > avoided by modifying the implementation to use thread-safe > APIs. The current _res stuff can _almost_ be eliminated > by passing using pthread_getspecific() once and passing > the _res around internal APIs. That's actually a pretty > simple change. Unfortunately pthread_setspecific() and pthread_getspecific() don't work for non-threaded programs whereas 'int __thread errno' works anywhere. It would even work for evil cases where libpthread is loaded after program startup with dlopen. From owner-freebsd-threads@FreeBSD.ORG Tue Mar 30 06:13:35 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 E60FF16A4CE for ; Tue, 30 Mar 2004 06:13:35 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id A011943D45 for ; Tue, 30 Mar 2004 06:13:35 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i2UEDYtf013265; Tue, 30 Mar 2004 09:13:34 -0500 (EST) Date: Tue, 30 Mar 2004 09:13:34 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Doug Rabson In-Reply-To: <200403300935.49999.dfr@nlsystems.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: Thread Local Storage 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: Tue, 30 Mar 2004 14:13:36 -0000 On Tue, 30 Mar 2004, Doug Rabson wrote: > On Monday 29 March 2004 23:36, Daniel Eischen wrote: > > I'd like to see libc free of TLS ;-) The _res stuff can be > > avoided by modifying the implementation to use thread-safe > > APIs. The current _res stuff can _almost_ be eliminated > > by passing using pthread_getspecific() once and passing > > the _res around internal APIs. That's actually a pretty > > simple change. > > Unfortunately pthread_setspecific() and pthread_getspecific() don't work > for non-threaded programs whereas 'int __thread errno' works anywhere. It works for libc, since libc knows whether it is threaded or not. I think libc is always going to be sort of special, especially since we seem to need the jump table for the pthread_* functions to handle the static case. I'd be in favor of not providing static thread libraries, but there was too much opposition when I brought it up... > It would even work for evil cases where libpthread is loaded after > program startup with dlopen. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Tue Mar 30 06:40:50 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 C4E5D16A4CE for ; Tue, 30 Mar 2004 06:40:50 -0800 (PST) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBE2F43D2F for ; Tue, 30 Mar 2004 06:40:49 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from bluebottle.qubesoft.com (bluebottle.qubesoft.com [192.168.1.2]) by mail.qubesoft.com (8.12.9/8.12.9) with ESMTP id i2UEelkM088956; Tue, 30 Mar 2004 15:40:47 +0100 (BST) (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) i2UEekUQ034248; Tue, 30 Mar 2004 15:40:47 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Daniel Eischen In-Reply-To: References: Content-Type: text/plain Message-Id: <1080657646.18663.9.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 30 Mar 2004 15:40:46 +0100 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: freebsd-threads@freebsd.org Subject: Re: Thread Local Storage 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: Tue, 30 Mar 2004 14:40:50 -0000 On Tue, 2004-03-30 at 15:13, Daniel Eischen wrote: > On Tue, 30 Mar 2004, Doug Rabson wrote: > > > On Monday 29 March 2004 23:36, Daniel Eischen wrote: > > > I'd like to see libc free of TLS ;-) The _res stuff can be > > > avoided by modifying the implementation to use thread-safe > > > APIs. The current _res stuff can _almost_ be eliminated > > > by passing using pthread_getspecific() once and passing > > > the _res around internal APIs. That's actually a pretty > > > simple change. > > > > Unfortunately pthread_setspecific() and pthread_getspecific() don't work > > for non-threaded programs whereas 'int __thread errno' works anywhere. > > It works for libc, since libc knows whether it is threaded > or not. I think libc is always going to be sort of special, > especially since we seem to need the jump table for the > pthread_* functions to handle the static case. Right now, the stubs for setspecific and getspecific are too simplistic which means that libc can't use them for anything interesting. The nice part of using TLS for errno is that libc doesn't have to care whether or not its threaded (in this tiny area, anyway). It even makes it straightforward to preserve the value of errno (or any other thread-specific value) when a threading library is loaded. Anyway, this is all blue-sky stuff which isn't relavent to the matter in hand. I was just getting into the whole TLS thing, which is kind of neat (IMHO) :-) > > I'd be in favor of not providing static thread libraries, > but there was too much opposition when I brought it up... Bah. Static sucks. The only way I can see to make TLS work for static is to implement it in the kernel and setup %gs in setregs :-(. From owner-freebsd-threads@FreeBSD.ORG Tue Mar 30 10:03:24 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 05EDC16A4CE for ; Tue, 30 Mar 2004 10:03:24 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id C20FC43D1F for ; Tue, 30 Mar 2004 10:03:23 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (localhost [127.0.0.1]) by ns1.xcllnt.net (8.12.11/8.12.11) with ESMTP id i2UI3NLh057895; Tue, 30 Mar 2004 10:03:23 -0800 (PST) (envelope-from marcel@ns1.xcllnt.net) Received: (from marcel@localhost) by ns1.xcllnt.net (8.12.11/8.12.11/Submit) id i2UI3NTa057894; Tue, 30 Mar 2004 10:03:23 -0800 (PST) (envelope-from marcel) Date: Tue, 30 Mar 2004 10:03:23 -0800 From: Marcel Moolenaar To: Doug Rabson Message-ID: <20040330180323.GA57824@ns1.xcllnt.net> References: <200403300935.49999.dfr@nlsystems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403300935.49999.dfr@nlsystems.com> User-Agent: Mutt/1.5.5.1i cc: freebsd-threads@freebsd.org Subject: Re: Thread Local Storage 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: Tue, 30 Mar 2004 18:03:24 -0000 On Tue, Mar 30, 2004 at 09:35:49AM +0100, Doug Rabson wrote: > > > > > > I'd quite like to see us use it for stuff like errno, _res and > > > other uglification currently in libc. Not until the 6.x timeframe > > > though. > > > > I'd like to see libc free of TLS ;-) The _res stuff can be > > avoided by modifying the implementation to use thread-safe > > APIs. The current _res stuff can _almost_ be eliminated > > by passing using pthread_getspecific() once and passing > > the _res around internal APIs. That's actually a pretty > > simple change. > > Unfortunately pthread_setspecific() and pthread_getspecific() don't work > for non-threaded programs whereas 'int __thread errno' works anywhere. Yes. It's also far more optimal. > It would even work for evil cases where libpthread is loaded after > program startup with dlopen. Yup. I think it's important to have it work. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-threads@FreeBSD.ORG Tue Mar 30 10:05:10 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 61E8916A4CE for ; Tue, 30 Mar 2004 10:05:10 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2EEFC43D46 for ; Tue, 30 Mar 2004 10:05:10 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (localhost [127.0.0.1]) by ns1.xcllnt.net (8.12.11/8.12.11) with ESMTP id i2UI59ao057905; Tue, 30 Mar 2004 10:05:09 -0800 (PST) (envelope-from marcel@ns1.xcllnt.net) Received: (from marcel@localhost) by ns1.xcllnt.net (8.12.11/8.12.11/Submit) id i2UI599B057904; Tue, 30 Mar 2004 10:05:09 -0800 (PST) (envelope-from marcel) Date: Tue, 30 Mar 2004 10:05:09 -0800 From: Marcel Moolenaar To: Doug Rabson Message-ID: <20040330180509.GB57824@ns1.xcllnt.net> References: <1080657646.18663.9.camel@builder02.qubesoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1080657646.18663.9.camel@builder02.qubesoft.com> User-Agent: Mutt/1.5.5.1i cc: freebsd-threads@freebsd.org Subject: Re: Thread Local Storage 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: Tue, 30 Mar 2004 18:05:10 -0000 On Tue, Mar 30, 2004 at 03:40:46PM +0100, Doug Rabson wrote: > > > > I'd be in favor of not providing static thread libraries, > > but there was too much opposition when I brought it up... > > Bah. Static sucks. The only way I can see to make TLS work for static is > to implement it in the kernel and setup %gs in setregs :-(. Yes. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-threads@FreeBSD.ORG Wed Mar 31 01:27:24 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 C83AA16A4CE for ; Wed, 31 Mar 2004 01:27:24 -0800 (PST) Received: from herring.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id BED0743D49 for ; Wed, 31 Mar 2004 01:27:23 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from herring.rabson.org (herring.rabson.org [10.0.0.2]) by herring.rabson.org (8.12.11/8.12.11) with ESMTP id i2V9QaT3024255; Wed, 31 Mar 2004 10:26:36 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Julian Elischer Date: Wed, 31 Mar 2004 10:26:35 +0100 User-Agent: KMail/1.6.1 References: <200403292000.13794.dfr@nlsystems.com> <40687814.70208@elischer.org> In-Reply-To: <40687814.70208@elischer.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403311026.35724.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on herring.rabson.org X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: freebsd-threads@freebsd.org Subject: Re: Thread Local Storage 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: Wed, 31 Mar 2004 09:27:25 -0000 On Monday 29 March 2004 20:25, Julian Elischer wrote: > there is a KSE p4 tree that is curently unused as we have everything > in CVS at the moment.. I sync'ed to this tree but its a little out-of-date (2 years ish). Could someone who understands p4 better than me try to put together a more recent tree with at least libexec/rtld-elf, sys, lib/libc, lib/libpthread and lib/libthr in it, thanks. From owner-freebsd-threads@FreeBSD.ORG Wed Mar 31 01:58:19 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 511F916A4FA for ; Wed, 31 Mar 2004 01:58:19 -0800 (PST) Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id F0B8143D5E for ; Wed, 31 Mar 2004 01:58:16 -0800 (PST) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-216-100-132-94.dsl.snfc21.pacbell.net [216.100.132.94])i2V9wEQi091704; Wed, 31 Mar 2004 04:58:15 -0500 Message-ID: <406A95C8.8050109@elischer.org> Date: Wed, 31 Mar 2004 01:56:24 -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: Doug Rabson References: <200403292000.13794.dfr@nlsystems.com> <40687814.70208@elischer.org> <200403311026.35724.dfr@nlsystems.com> In-Reply-To: <200403311026.35724.dfr@nlsystems.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: Thread Local Storage 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: Wed, 31 Mar 2004 09:58:19 -0000 Doug Rabson wrote: > On Monday 29 March 2004 20:25, Julian Elischer wrote: > >>there is a KSE p4 tree that is curently unused as we have everything >>in CVS at the moment.. > > > I sync'ed to this tree but its a little out-of-date (2 years ish). Could > someone who understands p4 better than me try to put together a more > recent tree with at least libexec/rtld-elf, sys, lib/libc, > lib/libpthread and lib/libthr in it, thanks. > I've brought what is there up to date but I forget how to add new sections of the tree (e.g. libthr) I'll try add libexec/rtld-elf, lib/libthr, lib/libpthread, ib/libc as soon as I work out what the command is :-) -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v From owner-freebsd-threads@FreeBSD.ORG Wed Mar 31 02:40:00 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 35DBE16A4CE for ; Wed, 31 Mar 2004 02:40:00 -0800 (PST) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8883C43D2F for ; Wed, 31 Mar 2004 02:39:59 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from bluebottle.qubesoft.com (bluebottle.qubesoft.com [192.168.1.2]) by mail.qubesoft.com (8.12.9/8.12.9) with ESMTP id i2VAdLkM020223; Wed, 31 Mar 2004 11:39:22 +0100 (BST) (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) i2VAdJUQ054770; Wed, 31 Mar 2004 11:39:20 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Julian Elischer In-Reply-To: <406A95C8.8050109@elischer.org> References: <200403292000.13794.dfr@nlsystems.com> <40687814.70208@elischer.org> <200403311026.35724.dfr@nlsystems.com> <406A95C8.8050109@elischer.org> Content-Type: text/plain Message-Id: <1080729559.19486.0.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 31 Mar 2004 11:39:19 +0100 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: freebsd-threads@freebsd.org Subject: Re: Thread Local Storage 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: Wed, 31 Mar 2004 10:40:00 -0000 On Wed, 2004-03-31 at 10:56, Julian Elischer wrote: > Doug Rabson wrote: > > On Monday 29 March 2004 20:25, Julian Elischer wrote: > > > >>there is a KSE p4 tree that is curently unused as we have everything > >>in CVS at the moment.. > > > > > > I sync'ed to this tree but its a little out-of-date (2 years ish). Could > > someone who understands p4 better than me try to put together a more > > recent tree with at least libexec/rtld-elf, sys, lib/libc, > > lib/libpthread and lib/libthr in it, thanks. > > > > I've brought what is there up to date but I forget how to add new sections of > the tree (e.g. libthr) > I'll try add libexec/rtld-elf, lib/libthr, lib/libpthread, ib/libc > as soon as I work out what the command is :-) Thanks - do you know how I can arrange to get commit mail for it? From owner-freebsd-threads@FreeBSD.ORG Wed Mar 31 11:01:58 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 5F5F716A4CE for ; Wed, 31 Mar 2004 11:01:58 -0800 (PST) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A20043D5A for ; Wed, 31 Mar 2004 11:01:58 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc11) with ESMTP id <2004033119015701300182lae>; Wed, 31 Mar 2004 19:01:57 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA56768; Wed, 31 Mar 2004 11:01:56 -0800 (PST) Date: Wed, 31 Mar 2004 11:01:56 -0800 (PST) From: Julian Elischer To: Doug Rabson In-Reply-To: <1080729559.19486.0.camel@builder02.qubesoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: Thread Local Storage 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: Wed, 31 Mar 2004 19:01:58 -0000 On 31 Mar 2004, Doug Rabson wrote: > On Wed, 2004-03-31 at 10:56, Julian Elischer wrote: > > Doug Rabson wrote: > > > On Monday 29 March 2004 20:25, Julian Elischer wrote: > > > > > >>there is a KSE p4 tree that is curently unused as we have everything > > >>in CVS at the moment.. > > > > > > > > > I sync'ed to this tree but its a little out-of-date (2 years ish). Could > > > someone who understands p4 better than me try to put together a more > > > recent tree with at least libexec/rtld-elf, sys, lib/libc, > > > lib/libpthread and lib/libthr in it, thanks. > > > > > > > I've brought what is there up to date but I forget how to add new sections of > > the tree (e.g. libthr) > > I'll try add libexec/rtld-elf, lib/libthr, lib/libpthread, ib/libc > > as soon as I work out what the command is :-) > > Thanks - do you know how I can arrange to get commit mail for it? > I'm lookig for my cheat sheets :-) > > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" > From owner-freebsd-threads@FreeBSD.ORG Wed Mar 31 23:48:49 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 B643316A4CE for ; Wed, 31 Mar 2004 23:48:49 -0800 (PST) Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3184943D1D for ; Wed, 31 Mar 2004 23:48:49 -0800 (PST) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-216-100-132-94.dsl.snfc21.pacbell.net [216.100.132.94])i317mlj7124994; Thu, 1 Apr 2004 02:48:48 -0500 Message-ID: <406BC8F3.2050709@elischer.org> Date: Wed, 31 Mar 2004 23:46:59 -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: Doug Rabson References: <200403292000.13794.dfr@nlsystems.com> <40687814.70208@elischer.org> <200403311026.35724.dfr@nlsystems.com> <406A95C8.8050109@elischer.org> <1080729559.19486.0.camel@builder02.qubesoft.com> In-Reply-To: <1080729559.19486.0.camel@builder02.qubesoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: Thread Local Storage 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: Thu, 01 Apr 2004 07:48:49 -0000 Doug Rabson wrote: > On Wed, 2004-03-31 at 10:56, Julian Elischer wrote: > >>Doug Rabson wrote: >> >>>On Monday 29 March 2004 20:25, Julian Elischer wrote: >>> >>> >>>>there is a KSE p4 tree that is curently unused as we have everything >>>>in CVS at the moment.. >>> >>> >>>I sync'ed to this tree but its a little out-of-date (2 years ish). Could >>>someone who understands p4 better than me try to put together a more >>>recent tree with at least libexec/rtld-elf, sys, lib/libc, >>>lib/libpthread and lib/libthr in it, thanks. >>> >> >>I've brought what is there up to date but I forget how to add new sections of >>the tree (e.g. libthr) >>I'll try add libexec/rtld-elf, lib/libthr, lib/libpthread, ib/libc >>as soon as I work out what the command is :-) > > > Thanks - do you know how I can arrange to get commit mail for it? > > > found my cheatsheet.. p4 branch kse edit to add directories you want p4 opened p4 sync p4 integrate -b kse p4 resolve -a p4 resolve p4 submit to add yourself to the mailing lis for it.. p4 user add the kse branch to your "reviews" section.. here's mine: ----------------------------- User: julian Email: julian@freebsd.org Update: 2001/07/16 23:48:14 Access: 2004/03/31 23:41:57 FullName: Julian Elischer Password: ****** Reviews: //depot/projects/smpng/... //depot/projects/kse/... //depot/user/julian/... //depot/user/jhb/... //depot/doc/... ----------------------------------- -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v From owner-freebsd-threads@FreeBSD.ORG Thu Apr 1 00:07:12 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 587E116A4CE for ; Thu, 1 Apr 2004 00:07:12 -0800 (PST) Received: from herring.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9075A43D5D for ; Thu, 1 Apr 2004 00:07:11 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from herring.rabson.org (herring.rabson.org [10.0.0.2]) by herring.rabson.org (8.12.11/8.12.11) with ESMTP id i3186R9r031324; Thu, 1 Apr 2004 09:06:27 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Julian Elischer Date: Thu, 1 Apr 2004 09:06:27 +0100 User-Agent: KMail/1.6.1 References: <200403292000.13794.dfr@nlsystems.com> <1080729559.19486.0.camel@builder02.qubesoft.com> <406BC8F3.2050709@elischer.org> In-Reply-To: <406BC8F3.2050709@elischer.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200404010906.27230.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on herring.rabson.org X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: freebsd-threads@freebsd.org Subject: Re: Thread Local Storage 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: Thu, 01 Apr 2004 08:07:12 -0000 On Thursday 01 April 2004 08:46, Julian Elischer wrote: > Doug Rabson wrote: > > On Wed, 2004-03-31 at 10:56, Julian Elischer wrote: > >>Doug Rabson wrote: > >>>On Monday 29 March 2004 20:25, Julian Elischer wrote: > >>>>there is a KSE p4 tree that is curently unused as we have > >>>> everything in CVS at the moment.. > >>> > >>>I sync'ed to this tree but its a little out-of-date (2 years ish). > >>> Could someone who understands p4 better than me try to put > >>> together a more recent tree with at least libexec/rtld-elf, sys, > >>> lib/libc, lib/libpthread and lib/libthr in it, thanks. > >> > >>I've brought what is there up to date but I forget how to add new > >> sections of the tree (e.g. libthr) > >>I'll try add libexec/rtld-elf, lib/libthr, lib/libpthread, ib/libc > >>as soon as I work out what the command is :-) > > > > Thanks - do you know how I can arrange to get commit mail for it? > > found my cheatsheet.. Excellent. Thats exactly what I need, thanks. > ----------------------------------- From owner-freebsd-threads@FreeBSD.ORG Fri Apr 2 11:40:15 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 1B7F016A4CF; Fri, 2 Apr 2004 11:40:15 -0800 (PST) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id B63DD43D45; Fri, 2 Apr 2004 11:40:14 -0800 (PST) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-216-100-132-94.dsl.snfc21.pacbell.net [216.100.132.94])i32JeC1Y249496; Fri, 2 Apr 2004 14:40:12 -0500 Message-ID: <406DC12E.5060404@elischer.org> Date: Fri, 02 Apr 2004 11:38:22 -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: Doug Rabson , Daniel Eischen , threads@freebsd.org, Peter Wemm , Marcel Moolenaar References: <200404021443.i32EhAP9009274@repoman.freebsd.org> <1080926920.4652.1.camel@builder02.qubesoft.com> <406DB178.2000205@elischer.org> <200404021957.02922.dfr@nlsystems.com> In-Reply-To: <200404021957.02922.dfr@nlsystems.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: Fri, 02 Apr 2004 19:40:15 -0000 Doug Rabson wrote: > On Friday 02 April 2004 19:31, Julian Elischer wrote: > >>Doug Rabson wrote: >> >>>On Fri, 2004-04-02 at 17:47, Julian Elischer wrote: >>> >>>>And the crowd goes wild... >>> >>>I'm not convinced that rtld is quite right yet. In particular, >>>stuff like: >>> int __thread x[10]; >>> &x[5]; >>> >>>is probably broken. >>> >>>FWIW, our binutils doen't support the Sun abi at all... >> >>hmmm I wonder if it's planned or if we have to do it.. > > > Personally, I don't see the point. The GNU abi is smaller and faster and > will be better maintained by the gnu people over time. There isn't any > choice for any of the other platforms, including amd64 (which uses a > gnu-style abi with %fs:0 == %fs). So we are screwed for amd64 basically. But the reason the sun ABI axists is because on a PC using %gs as a segment register for thread identification, you cannot use the GNU model unless you are using 1:1 threads. You need to be able to change the place the pointer points from userland. Obviously this requires a syscall as changing a [gl]dt entry can not be done by a user process. This means that every context switch would require a syscall which defeats the entire point of using M:N threads. 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. Processors that have a "thread pointer" register are ok because the UTS can just change it whenever it switches threads. Unfortunatly the X86 requires that we use a priviledged operation. The only thing I can see as a possibility is if we make a special trap into the kernel (bypassing all the normal syscall code) that takes a single register as an argument and puts it into the segment register descriptor pointed to by %gs after checking it VERY quickly, and returns.. it may be possible to get in and out of the kernel quick enough that we don't lose performance. -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v From owner-freebsd-threads@FreeBSD.ORG Fri Apr 2 12:22:55 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 6343716A4CF for ; Fri, 2 Apr 2004 12:22:55 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E64943D31 for ; Fri, 2 Apr 2004 12:22:55 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i32KMntf006944; Fri, 2 Apr 2004 15:22:49 -0500 (EST) Date: Fri, 2 Apr 2004 15:22:49 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Julian Elischer In-Reply-To: <406DC12E.5060404@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: Fri, 02 Apr 2004 20:22:55 -0000 On Fri, 2 Apr 2004, Julian Elischer wrote: > Doug Rabson wrote: > > On Friday 02 April 2004 19:31, Julian Elischer wrote: > > > >>Doug Rabson wrote: > >> > >>>On Fri, 2004-04-02 at 17:47, Julian Elischer wrote: > >>> > >>>>And the crowd goes wild... > >>> > >>>I'm not convinced that rtld is quite right yet. In particular, > >>>stuff like: > >>> int __thread x[10]; > >>> &x[5]; > >>> > >>>is probably broken. > >>> > >>>FWIW, our binutils doen't support the Sun abi at all... > >> > >>hmmm I wonder if it's planned or if we have to do it.. > > > > > > Personally, I don't see the point. The GNU abi is smaller and faster and > > will be better maintained by the gnu people over time. There isn't any > > choice for any of the other platforms, including amd64 (which uses a > > gnu-style abi with %fs:0 == %fs). > > So we are screwed for amd64 basically. > > > But the reason the sun ABI axists is because on a PC using %gs as a segment > register for thread identification, you cannot use the GNU model unless you > are using 1:1 threads. You need to be able to change the place the pointer > points from userland. Obviously this requires a syscall as changing a [gl]dt > entry can not be done by a user process. This means that every context switch > would require a syscall which defeats the entire point of using M:N threads. > > 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. > Processors that have a "thread pointer" register are ok because the UTS > can just change it whenever it switches threads. Unfortunatly the X86 > requires that we use a priviledged operation. > The only thing I can see as a possibility is if we make a special trap > into the kernel (bypassing all the normal syscall code) > that takes a single register as an argument and puts it into the > segment register descriptor pointed to by %gs after checking it VERY quickly, > and returns.. it may be possible to get in and out of the kernel quick enough > that we don't lose performance. How do I get P4 commit mail? -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Fri Apr 2 12:47:10 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 D711D16A4E6 for ; Fri, 2 Apr 2004 12:47:10 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C7DF43D2F for ; Fri, 2 Apr 2004 12:47:10 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 335F15313; Fri, 2 Apr 2004 22:47:09 +0200 (CEST) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 7BEEF530A; Fri, 2 Apr 2004 22:47:04 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id 2718733CAA; Fri, 2 Apr 2004 22:47:04 +0200 (CEST) To: Daniel Eischen References: From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Fri, 02 Apr 2004 22:47:04 +0200 In-Reply-To: (Daniel Eischen's message of "Fri, 2 Apr 2004 15:22:49 -0500 (EST)") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: threads@freebsd.org cc: Julian Elischer 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: Fri, 02 Apr 2004 20:47:11 -0000 Daniel Eischen writes: > How do I get P4 commit mail? Ask peter@ and / or perforce-users@. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-threads@FreeBSD.ORG Fri Apr 2 13:12:34 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 4CBF816A4CE for ; Fri, 2 Apr 2004 13:12:34 -0800 (PST) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F29C43D46 for ; Fri, 2 Apr 2004 13:12:34 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc11) with ESMTP id <2004040221123201100c4us0e>; Fri, 2 Apr 2004 21:12:33 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA84820; Fri, 2 Apr 2004 13:12:31 -0800 (PST) Date: Fri, 2 Apr 2004 13:12:30 -0800 (PST) From: Julian Elischer To: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE 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: Fri, 02 Apr 2004 21:12:34 -0000 On Fri, 2 Apr 2004, Dag-Erling [iso-8859-1] Sm=F8rgrav wrote: > Daniel Eischen writes: > > How do I get P4 commit mail? >=20 > Ask peter@ and / or perforce-users@. p4 user edit list of branches you wish to watch >=20 > DES > --=20 > Dag-Erling Sm=F8rgrav - des@des.no >=20 From owner-freebsd-threads@FreeBSD.ORG Sat Apr 3 00:00:16 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 BD0F416A4CE; Sat, 3 Apr 2004 00:00:16 -0800 (PST) Received: from herring.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABBFC43D31; Sat, 3 Apr 2004 00:00:15 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from herring.rabson.org (herring.rabson.org [10.0.0.2]) by herring.rabson.org (8.12.11/8.12.11) with ESMTP id i337xUao008859; Sat, 3 Apr 2004 08:59:30 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Julian Elischer Date: Sat, 3 Apr 2004 08:59:29 +0100 User-Agent: KMail/1.6.1 References: <200404021443.i32EhAP9009274@repoman.freebsd.org> <200404021957.02922.dfr@nlsystems.com> <406DC12E.5060404@elischer.org> In-Reply-To: <406DC12E.5060404@elischer.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200404030859.29886.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on herring.rabson.org X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: Daniel Eischen 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 08:00:16 -0000 On Friday 02 April 2004 20:38, Julian Elischer wrote: > Doug Rabson wrote: > > On Friday 02 April 2004 19:31, Julian Elischer wrote: > >>Doug Rabson wrote: > >>>On Fri, 2004-04-02 at 17:47, Julian Elischer wrote: > >>>>And the crowd goes wild... > >>> > >>>I'm not convinced that rtld is quite right yet. In particular, > >>>stuff like: > >>> int __thread x[10]; > >>> &x[5]; > >>> > >>>is probably broken. > >>> > >>>FWIW, our binutils doen't support the Sun abi at all... > >> > >>hmmm I wonder if it's planned or if we have to do it.. > > > > Personally, I don't see the point. The GNU abi is smaller and > > faster and will be better maintained by the gnu people over time. > > There isn't any choice for any of the other platforms, including > > amd64 (which uses a gnu-style abi with %fs:0 == %fs). > > So we are screwed for amd64 basically. > Yes. > > But the reason the sun ABI axists is because on a PC using %gs as a > segment register for thread identification, you cannot use the GNU > model unless you are using 1:1 threads. You need to be able to > change the place the pointer points from userland. Obviously this > requires a syscall as changing a [gl]dt entry can not be done by a > user process. This means that every context switch would require a > syscall which defeats the entire point of using M:N threads. > > 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. It is not true that the GNU model can only work for 1:1 threading. I can think of at least two ways of arranging for %gs:0==%gs without adding significant overhead to the userland thread switch code and without using syscalls in the common path. > > Processors that have a "thread pointer" register are ok because the > UTS can just change it whenever it switches threads. Unfortunatly the > X86 requires that we use a priviledged operation. > The only thing I can see as a possibility is if we make a special > trap into the kernel (bypassing all the normal syscall code) > that takes a single register as an argument and puts it into the > segment register descriptor pointed to by %gs after checking it VERY > quickly, and returns.. it may be possible to get in and out of the > kernel quick enough that we don't lose performance. This might work, e.g. if we pre-allocate a per-cpu GDT entry for this purpose and this special trap merely changes the base address of this pre-initialised GDT. I've just taken a look at the latest binutils cvs and gas does not have any support for the relocations required for the Sun abi (e.g. x@DTLNDX, x@TLSPLT). Given that the code relaxation optimisations which are to be performed by the linker are much trickier for the Sun abi, I doubt that ld supports it either. Lets just look at the pros and cons here: Sun ABI Pros Cons Works with todays libpthread We would need to branch binutils and maintain that branch forever Code size and speed are poor We would be using a mode of the compiler which no-one else really cares about GNU ABI Pros Cons Supported by binutils and gcc today We have to add ~5 lines of code to the userland thread switch Small and fast code - easy to optimise at link time Everyone else using gnu tools uses this mode so its well maintained From owner-freebsd-threads@FreeBSD.ORG Sat Apr 3 00:01:33 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 3D81016A4CE for ; Sat, 3 Apr 2004 00:01:33 -0800 (PST) Received: from herring.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2F1E43D2D for ; Sat, 3 Apr 2004 00:01:31 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from herring.rabson.org (herring.rabson.org [10.0.0.2]) by herring.rabson.org (8.12.11/8.12.11) with ESMTP id i3380mVM008888; Sat, 3 Apr 2004 09:00:48 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Daniel Eischen Date: Sat, 3 Apr 2004 09:00:48 +0100 User-Agent: KMail/1.6.1 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200404030900.48492.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on herring.rabson.org X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: threads@freebsd.org cc: Julian Elischer 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 08:01:33 -0000 On Friday 02 April 2004 21:22, Daniel Eischen wrote: > How do I get P4 commit mail? Use 'p4 user' and add '//depot/projects/kse/...' to your 'Reviews' section. From owner-freebsd-threads@FreeBSD.ORG Sat Apr 3 09:24:43 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 9210D16A4CE for ; Sat, 3 Apr 2004 09:24:43 -0800 (PST) Received: from herring.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7892A43D53 for ; Sat, 3 Apr 2004 09:24:42 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from herring.rabson.org (herring.rabson.org [10.0.0.2]) by herring.rabson.org (8.12.11/8.12.11) with ESMTP id i33HNtUP069511; Sat, 3 Apr 2004 18:23:55 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Daniel Eischen Date: Sat, 3 Apr 2004 18:23:54 +0100 User-Agent: KMail/1.6.1 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200404031823.54815.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on herring.rabson.org X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: threads@freebsd.org cc: Julian Elischer 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 17:24:43 -0000 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. 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 Although I'm still not quite convinced that we can't do the first version with essentially zero cost for i386 at least. From owner-freebsd-threads@FreeBSD.ORG Sat Apr 3 10:22:51 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 B86BB16A4CE for ; Sat, 3 Apr 2004 10:22:51 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 728AF43D5C for ; Sat, 3 Apr 2004 10:22:51 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i33IMitf000290; Sat, 3 Apr 2004 13:22:44 -0500 (EST) Date: Sat, 3 Apr 2004 13:22:44 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Doug Rabson In-Reply-To: <200404031823.54815.dfr@nlsystems.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org cc: Julian Elischer 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 18:22:51 -0000 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... > 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. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sat Apr 3 11:29:39 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 1EF8916A4CE for ; Sat, 3 Apr 2004 11:29:39 -0800 (PST) Received: from herring.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DCDD43D58 for ; Sat, 3 Apr 2004 11:29:38 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from herring.rabson.org (herring.rabson.org [10.0.0.2]) by herring.rabson.org (8.12.11/8.12.11) with ESMTP id i33JSp8A093874; Sat, 3 Apr 2004 20:28:51 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Daniel Eischen Date: Sat, 3 Apr 2004 20:28:50 +0100 User-Agent: KMail/1.6.1 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200404032028.50715.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on herring.rabson.org X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: threads@freebsd.org cc: Julian Elischer 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 19:29:39 -0000 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. From owner-freebsd-threads@FreeBSD.ORG Sat Apr 3 14:07:15 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 A9A6A16A4CE for ; Sat, 3 Apr 2004 14:07:15 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FBC343D55 for ; Sat, 3 Apr 2004 14:07:15 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i33M79tf019791; Sat, 3 Apr 2004 17:07:10 -0500 (EST) Date: Sat, 3 Apr 2004 17:07:09 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Doug Rabson In-Reply-To: <200404032028.50715.dfr@nlsystems.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org cc: Julian Elischer 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:07:15 -0000 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. -- Dan Eischen 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 From owner-freebsd-threads@FreeBSD.ORG Sat Apr 3 14:29:13 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 C0CF616A4CE for ; Sat, 3 Apr 2004 14:29:13 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5447343D5A for ; Sat, 3 Apr 2004 14:29:13 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i33MT8tf024763; Sat, 3 Apr 2004 17:29:08 -0500 (EST) Date: Sat, 3 Apr 2004 17:29:08 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Julian Elischer In-Reply-To: <406F37F3.3050501@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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:29:13 -0000 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