Date: Sun, 28 Nov 1999 21:09:08 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: arch@freebsd.org Subject: Re: Threads stuff Message-ID: <Pine.BSF.4.10.9911282059000.544-100000@current1.whistle.com> In-Reply-To: <199911290048.QAA47070@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 28 Nov 1999, Matthew Dillon wrote: > :We are rforking to make subprocs. a subproc runs at one priority on one CPU. > :it has it's struct proc, (or most of one :-) and the threads are assigned > :to it. Any KSE that is created is automatically hung off that subproc. > :it will ony be run on that cpu unles there is intervention. > :(of which there may be may types, fro example a related subproc may be totally idle at teh time a KSE becomes unblocked.. it would be a waste to not use that other CPU) > > This seems like an added unnecessary complication that would be > difficult to scale dynamically to different topologies. Or, put another > way, the burden of knowledge is much greater with this scheme then with > other schemes. Think of the subprocs as "virtual processors" (your terminology) you would have one for each processor for maximum parallelism, but posibly a couple extra if you wanted a virtual processor that was to run at a higher priority > > You already have KSE's, that's all the execution environment you really > need. The KSE's will have an associated process, but the kernel is able > to schedule KSE's across available cpu's even if several are > associated with the same process. Every *active* thread needs to have > an active KSE associated with it in order to handle faults, even if it > is not currently in a system call, which means that it is the KSE's > the kernel associates with a cpu, not a process. Runnable (but not > active) threads do not need KSE's associated with them if they are not > in the midst of a system call. By hangling KSEs and threads off virtual procesors (rforked procs) you can do thread classes, which is one of the requirements we came to in the requirements phase. Subprocesses can have some processor affinity, and they have system-wide priority. > > An outline of my scheme would simply be: > > * You have a process, the process has threads I want to add rforked subprocesses here . this gice us classes. everywhere below where you say "process" I add a preceding "sub-" :-) > > * Each thread has a kernel Thread (or Task) structure associated > with it. We agree on this, just not entirely on which 'space' they live in. How do you set policy for a kernel thread schedular? > > * KSE's are assigned to threads as needed, with only two cases that > *require* a KSE assignment. > > (1) When the thread is currently running on a cpu, a KSE must be > assigned to it even if the KSE's stack is not being used at > the moment. > > Reasoning: So the kernel can preemptively switch away from the > thread, take interrupts, faults, and other things. exactly > > (2) When the thread is blocked in a system call, a KSE must be > assigned to it to hold the kernel stack state. exactly > > If you do things this way then the implementation within the kernel > becomes trivial. The kernel scheduler only needs to know about KSE's > and MMU contexts (extracted from the associated struct proc), and that's > it. You can still impose scheduling requirements via a UTS by having > the UTS give 'hints' to the kernel, but the UTS would not be > *synchronously* required to wakeup a thread or put it to sleep. > > -Matt > Matthew Dillon > <dillon@backplane.com> 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.BSF.4.10.9911282059000.544-100000>