From owner-freebsd-arch Thu Nov 23 17:56:56 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 3CCB637B479; Thu, 23 Nov 2000 17:56:54 -0800 (PST) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id SAA16094; Thu, 23 Nov 2000 18:55:47 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp01.primenet.com, id smtpdAAA5fa4zF; Thu Nov 23 18:55:44 2000 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id SAA06496; Thu, 23 Nov 2000 18:56:44 -0700 (MST) From: Terry Lambert Message-Id: <200011240156.SAA06496@usr06.primenet.com> Subject: Re: Thread-specific data and KSEs To: eischen@vigrid.com (Daniel Eischen) Date: Fri, 24 Nov 2000 01:56:44 +0000 (GMT) Cc: jhb@FreeBSD.ORG (John Baldwin), tlambert@primenet.com (Terry Lambert), arch@FreeBSD.ORG, jlemon@flugsvamp.com, bright@wintelcom.net In-Reply-To: from "Daniel Eischen" at Nov 22, 2000 06:28:38 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > The %gs register already has to be saved for WINE processes, > > > so it's taken (at least when USER_LDT is defined). So there > > > would not be an additional context switch for it. > > > > Ok. Since %fs is only used in the kernel and is saved/restored > > it might be a good thing to use instead. > > I didn't think %fs was saved, but if it is, that's fine > with me too. I think this misses the original point: if the register is supposed to be a rendesvous between user and kernel space, it needs to be the same in kernel space, not "saved and changed". I think that %fs and %gs are saved, but not preserved in the kernel: they are per process. This may be enough, if the reload is done late enough, but it may not. After a wakeup, prior to an upcall, a KSE would need to have this value restored to its pre-sleep state; as pointed out in this thread already (first by Arun?), this may be too expensive. In fact, since the stack needs to be reloaded anyway, I'm partial to Alfred's suggestion, even though it makes stack length less determinate than it already is (the big drawback to Alfred's suggestion). > > It will be an indirect if I have any say in it. :) Currently > > we use %fs in the kernel to address a segment that contains > > per-CPU data. I think that if we use a seg reg, then we > > should have it address a segment that contains per-KSE data. > > Didn't Terry want an additional level of indirection? If we > have %fs address a segment containing per-KSE data, then I'd > like to place pointers to both the KSE struct and the thread struct > (2 slots) in this segment (this would remove 1 level of indirection > to "current thread"). I wanted the additional evel of indirection so that the next good reason gfor grabing %gs (or %fs) won't result in being impossible to implement. This means that I think the register should be associated with the most granular scheduling unit, and point to a table of values, the first element of which is whatever you guys are wanting to put in a register right now. This is an additional indirection, but it means that the next time someone needs some way to squirrel away data, it will be there, instead of being impossible without a large rewrite. The initial length of this table could be "one element". As your element would be the first element, there is no addition required to access it, so it's a direct dereference of the first element (a double dereference of the register), or an extra 6 cycles, according to the programming manual here... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message