Date: Wed, 25 Apr 2001 14:36:53 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Julian Elischer <julian@elischer.org> Cc: Arch@freebsd.org, alfred@freebsd.org, Robert Watson <rwatson@freebsd.org> Subject: Re: KSE threading support (first parts) Message-ID: <Pine.SUN.3.91.1010425141253.20558A-100000@pcnet1.pcnet.com> In-Reply-To: <3AE71067.FF4BD029@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 25 Apr 2001, Julian Elischer wrote: > 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. Don't we eventually want per-CPU run queues? Then how do multiple KSEs hanging off a KSEG get scheduled then if the quanta are in the KSEG? Round robin? > 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. Again, if KSEs can have a strong affinity for 1 processor and there can be multiple KSEs hanging off a KSEG, then how do you schedule these KSEs when we have per-CPU run queues? It makes scheduling these KSEs more difficult than it needs to be. I still don't see the need to have multiple KSEs within a KSEG ;-) > 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? Signals should be sent (via an upcall) to the first available KSE to return to userland (return from syscall, after preemption, etc.). The userland thread scheduler will pick a thread to receive the signal. If the thread is running or in one of the scheduling queues for the current KSEG, it will be able to handle it without any other assist from the kernel. If the thread is running or in one of the scheduling queues for another KSEG, it will mark the signal pending in the target thread and "signal" the appropriate KSEG with help from the kernel (one of the new user<->kernel interfaces or syscalls). (We may have to replace "KSEG" in the above with "KSE") It might be nice to have a general way of sending messages between KSEGs (KSEs?). > What happens to the 'u-area'? > > how do we define a "cur-kse" similar to curproc? > (do we need one?) > 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? > > Some of the next steps would be: > 1/ figure out what we want for signals etc.. Ask me for help in this area. I know what the userland scheduler has to do when dispatching signals to threads. > 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) > 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 Can't we start with 7 ;-) -- Dan Eischen 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?Pine.SUN.3.91.1010425141253.20558A-100000>