Date: Wed, 25 Apr 2001 11:09:40 -0700 From: Alfred Perlstein <alfred@FreeBSD.ORG> To: Julian Elischer <julian@elischer.org> Cc: Arch@FreeBSD.ORG, Robert Watson <rwatson@FreeBSD.ORG>, Daniel Eischen <eischen@vigrid.com> Subject: Re: KSE threading support (first parts) Message-ID: <20010425110940.L1790@fw.wintelcom.net> In-Reply-To: <3AE71067.FF4BD029@elischer.org>; from julian@elischer.org on Wed, Apr 25, 2001 at 10:59:03AM -0700 References: <3AE71067.FF4BD029@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* Julian Elischer <julian@elischer.org> [010425 11:00] wrote: > After discussing this with Jason Evans before he took his new position, > and having looked at his patches from December, and My similar patches from > january, here is a 'merged' patch. > > It breaks the proc structure into 4 parts. > > proc... owns all 'total process' resources. (e.g. address space, > limits, files) > kseg... KSE 'group'. Anything to do with working out the quanta to > be given to the threads (KSEs). A scheduling abstraction. > kse.... Actual scheduable entity for a processor > (if the KSEG has a quantum for it) > ksec... Where a thread stores its context when it is blocked > so tha the kse can return to either the user, or another > unblocked kse to continue using is quanta. > > This compiles cleanly and SHOULD run (it did run in an > earlier incarnation). It is by no means final, but rather > designed to give us a starting point in discussions. > > In this view, KSEGs are on the run queue and when they get some > quanta the KSEs hanging off them are run. > If 2 KSEs are running, the KSEG's quanta are exhausted a twice > the rate. > Each KSE has a very strong affinity for one processor > and KSECs have a weak affinity for a KSE. If a KSE runs out > of work but has time, it will 'poach' a KSEC from another KSE in the > same KSEG list. > > In this patch the linkages are not set up at all. > All that is done is that the structures are > defined and used instead of a monolithic 'proc' struct. > The new structures are 'included' in the proc structure > to maintain compatibility and to allow code to be changed slowely. > > What really needs to be done is for everyone who is interested to go over > rather arbitrary allocation of fields to structures that > I did and make suggested changes. > > Also I've punted on most things to do with signals as we haven't > really discussed how we want signals to be handled in a KSE world.. > (ca each KSEG or KSE get individual signals? do we need to > define a special 'signal' KSE? If so is that all it does? > > What happens to the 'u-area'? It makes sense that it stays except for struct pcb. Honestly swapping out the pcbs could be left as something to re-optimize later, they can take a signifigant amount of space, but nowadays it's not that big of a deal. > how do we define a "cur-kse" similar to curproc? > (do we need one?) yes. > 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. You should also ask John Baldwin about proc locking as this stuff is definetly going to require locking in order to function properly. > 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 on lwp the signal target. Most likely then signals would be still be in struct proc or the initial kse. > 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? > 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? -Alfred 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?20010425110940.L1790>