Date: Fri, 24 Nov 2000 01:56:44 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: eischen@vigrid.com (Daniel Eischen) Cc: jhb@FreeBSD.ORG (John Baldwin), tlambert@primenet.com (Terry Lambert), arch@FreeBSD.ORG, jlemon@flugsvamp.com, bright@wintelcom.net Subject: Re: Thread-specific data and KSEs Message-ID: <200011240156.SAA06496@usr06.primenet.com> In-Reply-To: <Pine.SUN.3.91.1001122182015.7920C-100000@pcnet1.pcnet.com> from "Daniel Eischen" at Nov 22, 2000 06:28:38 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011240156.SAA06496>