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