From owner-freebsd-arch Wed Nov 22 13: 6: 5 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id F10D437B4C5 for ; Wed, 22 Nov 2000 13:06:01 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id eAML5q047491; Wed, 22 Nov 2000 13:05:52 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 22 Nov 2000 13:06:04 -0800 (PST) From: John Baldwin To: Daniel Eischen Subject: Re: Thread-specific data and KSEs Cc: Arun Sharma , arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 22-Nov-00 Daniel Eischen wrote: > On Wed, 22 Nov 2000, John Baldwin wrote: >> On 22-Nov-00 Daniel Eischen wrote: >> > On Mon, 20 Nov 2000, Arun Sharma wrote: >> >> Linux threads implementation uses %gs to store a pointer to >> >> the thread structure. A segment register can only be loaded >> >> with a selector that points to a valid entry in a LDT or a GDT >> >> on x86. >> > >> > Hmm, OK. So if I initially load the LDT with entries (they >> > don't have to point to anything unless I want to really >> > use gs to point to something), then I can use gs. >> >> Entries in the LDT have to point to something, that's all they can do. You >> could in theory make them all be zero length or some such, but you might >> need >> more thread-local storage than a single 16-bit integer that would require 4k >> of >> backing store to avoid causing seg faults. If each KSE has its own LDT, on >> the >> other hand, then you can use a fixed entry in the LDT to point to the >> thread-local data (so that %gs doesn't have to change) much like we do for >> per-CPU data with %fs in the kernel. You can then use stuff similar to >> machine/globals.h to access each variable in the threaddata struct. > > I only really need KSE specific data, since each KSE _always_ knows > what thread it's running. When a KSE wants to run another thread, it > just changes the thread ID/pointer in the KSE specific data. So CURTHREAD > (or _thread_run for those of us that have fiddled with libc_r) would > just be CURKSE()->ksd_curthread. > > If I use the value of %gs (probably %gs>>3 - 17) as an index into > a global table of pointers to per-KSE structures, then I need not > worry about what is in the LDT, as long as it is valid. I wrote > a simple test program to load the remaining LDTs with the same > values as the LUDATA_SEL LDT, and this seemed to work nicely. Let %gs do its job. :) Seriously, look at how %fs is used in machine/globals.h. Have %gs:0 -> KSE specific data structure, then you can use %gs with fixed offsets to access KSE specific data. > I'll definitely check out your suggestion of using different entries > in the LDT for each KSE. Initially, it might make it easier to use > %gs as a simple index, so it is easier to validate the entry when > debugging the implementation. Eh, I would use a small LDT (LDT's don't have to be large if you don't have a lot of selectors) for each KSE with one statically configured selector that %gs is always set to that will point to the KSE data. Thus, when you create a KSE, you just setup its LDT to have the KSE data entry point to the KSE data. > Thanks, > > -- > Dan Eischen -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message