Date: Thu, 26 Apr 2001 11:49:14 -0700 (PDT) From: John Baldwin <jhb@FreeBSD.org> To: Julian Elischer <julian@elischer.org> Cc: Daniel Eischen <eischen@vigrid.com>, Robert Watson <rwatson@FreeBSD.org>, Arch@FreeBSD.org, Alfred Perlstein <alfred@FreeBSD.org>, jasone@FreeBSD.org Subject: Re: KSE threading support (first parts) Message-ID: <XFMail.010426114914.jhb@FreeBSD.org> In-Reply-To: <3AE85776.92D6BD90@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 26-Apr-01 Julian Elischer wrote: >> > how do we define a "cur-kse" similar to curproc? >> > (do we need one?) >> >> yes. > > I will look at seeing if I can do this... Trivially. Just use a per-cpu variable 'curkse' and do the equivalent of 's/curproc/PCPU_GET(curkse)/' as needed. Some other tweaks will be needed in some asm files as well, but that is easy. >> > presently the processor state is stored all over the place >> > when a process is suspended.. >> > This needs to be brought together so it can be put into the KSEC. >> > Who understands that stuff? >> >> That's your job. Refer to Jason Evans if he's available. > > gee thanks.. > I don't really have a grip on all the ways that traps etc > can need to save context.. > I REALLY don't get the floating point context stuff. > Some state is stored on the user tack, some on the kernel stack > and some in the pcb (and maybe some in the proc struct.) The pcb is used to save state while a thread is switched out. When a trap/exception/interrupt occurs the state is saved in a stack frame in the kernel. The FP state is a little tricky because we don't want to save it and restore it at every context switch, so we use a type of lazy switching where we only save it if we are using it and only restore it if we are using it, but a bit more complicated. All of this should be per-thread instead of per-proces and won't be that hard. Hardly any of this needs changing. > to complicate thigs a little: > Some things such as segment registers may be "per KSE" > where normal registers are "per KSEC". Stick all the registers in the same place. It doesn't hurt to duplicate the 4 seg regs in a couple of places, and the miniscule gain is hardly worth the extra effort involved. State like this really should be per-thread. >> You should also ask John Baldwin about proc locking as this >> stuff is definetly going to require locking in order to function >> properly. At first what Jason was planning on doing I think was just letting hte lock for the process lock all the kse's, kseg's, ksec's, etc. associated with a proc as well as the proc itself. I wouldn't worry too much about this at first. >> > Some of the next steps would be: >> > 1/ figure out what we want for signals etc.. >> >> Afaik Solaris tried many different ways to propogate signals across >> thier lwps, afaik they found the task so complex and so hard to get >> right that the latest implementation makes one lwp the signal target. >> >> Most likely then signals would be still be in struct proc or the >> initial kse. > > I was thinking about this.. > I think that signals should be delivered to the UTS > and it should be up to the UTS to decide what to do about it.. > In that case they would be delivered to the first available > kernel->user boundary crossing for that process. Userland is not available to create signal stacks, etc. You can make signals still be a process property adn the first kse (or ksec or whatever one is a runnable thread/context) that returns to userland from interrupt, etc. will execute ast() on the way out and post any signals. If you leave signals as being per-process I see there being hardly any changes needed in any of the signal handling code. >> > 2/ get the contexts actually stored in the KSEC structure >> > when a proces is suspended. (instead of some strange pcb in funny >> > memory >> > near the u area) >> >> huh? > > I mean that I get a headach when looking at where all the > registers, segment registers etc. are all stored as it looks as if > it's rather mixed up.. It'd be nice if it were all in one place, > and the KSEC is where that should be. The pcb should be per-thread, yes. >> > 3/ Set up the linkages between these structures, and >> > 4/ start using 'kse' instead of 'proc' in a bunch of places >> > and using the linkages to find the appropriate other >> > structures when needed. >> > 5/ Add code to make new KSEs so that the 1:1 Mapping is no longer >> > true. >> > 6/ Add syscalls to start making KSEs other than the one that >> > is built into the process. >> > 7/ start making upcalls >> > >> >> ok, when are you going to have these done? :) >> >> One other question, have you looked at the recent lwp/kse support added >> to NetBSD? Is there anything to learn/avoid? > > I've had only a small look so far > sorting hte wheat from the chaff is a hard task and of course it requires > understanding a lot that I'm not too solid on. (e.g. UVM). My only concern at this point in time is that I think 5.0 is fragile enough as it is. I'd rather that KSE not come in until 6.0-CURRENT so that 5.x has a fighting chance of being stable, but that is just my opinion. -- John Baldwin <jhb@FreeBSD.org> -- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.010426114914.jhb>