Date: Sat, 13 Nov 1999 13:16:03 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: "Daniel M. Eischen" <eischen@vigrid.com> Cc: Michael Schuster - TSC SunOS Germany <michael.schuster@germany.sun.com>, "freebsd-arch@FreeBSD.ORG" <freebsd-arch@freebsd.org> Subject: Re: Threads goals and implementation Message-ID: <Pine.BSF.4.10.9911131208050.21751-100000@current1.whistle.com> In-Reply-To: <382C0599.1E95429B@vigrid.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 12 Nov 1999, Daniel M. Eischen wrote: > Julian Elischer wrote: > > Here are my ideas. The terminology is not fixed. > > > > A PROCESS is the holder of all resources related to a single address > > space. The SA paper liked to call this an "Address Space" but I think we > > want to emphasise it's realtionship to a regular unix process. > > > > The PROCESS may 'fork' off several SUBPROCESSES. These share the resources > > of the process with the exception of their scheduling characteristics. > > >From a scheduling perspective they are the equivalent of child processes. > > > > Each SUBPROCESS is allocated one or more KERNEL SCHEDULABLE ENTITIES > > (KSE's). KSE' may be added to or removed from a SUBPROCESS as needed to > > prevent it from involuntarily block (except when it's quantum is exceeded)(*) > > > > The USER THREAD SCHEDULER assignes thread to KSE's and is aware of all > > threads entering and exiting the kernel. > > No, it is only aware of threads that block and unblock in the kernel. > The UTS should not know about _all_ kernel entry points, only those > entry points that are cancellable. I suppose that it is possible that > the mechanism used to notify the UTS of a thread blocking in the kernel > could also include the system call id/number in which the thread was > blocked, but it's not necessary from the UTS point of view. Well, When I say 'aware' I don't mean that it runs a UTS function , but just that it leaves some information behind saying where it has gone.. This allows the scheduler to make better decisions in the case of pre-emption and whether or not it needs more or less KSEs. The point is a large fraction of system calls can block. this is because the copyin() and copyout() functions can pagefault if the destination in userland is not physically present. If a process is pre-empted (Or should I say a sub-process, or KSE?)then when the next sub process for that process is entered, the scheduler should be run immediatly to decide which hread (possibly the pre-empted one) should be continued. This is only possible if the act of resumption can (1) go to the scheduler instead of the thread that was pre-empted, and (2) somehow make the pre-empted state available to the scheduler in the same way as the state for all other suspended threads are available. THere are some questions tht come up from this: 1/ should there be one sub-process for each processor/priority combination? Maybe there is one scheduler 'activation' (hmm) per subprocess? possibly for each subprocess there is only ever one KSE active, but possibly many blocked? Are blocked KSE's assigned to any subprocess, or are they only assigned to the process as a whole? > > > It can release KSE's and handle > > the case when a KSE blocks and another is provided as a replacement, It > > is probably also aware when a KSE is prempted (though only when that > > PROCESS is next run) (i.e. control returns to the UTS, withthe thread's > > state available, rather than directly to the thread. The UTS can chose to > > load that state adn keep running, or allow some other thread to run, > > depending upon whether there are deadlock or similar ramifications. > > > > KSE's from several SUBPROCESSSES may be running simultaniously in an SMP > > system, but which threads are in them is decided by the UTS. > > > > We may need to implement THREAD system calls through a different callgate > > to allow the different call/return convensions. > > I don't see why this would be necessary. A separate system call to > notify the kernel that the process and/or KSEs are using SAs (or whatever > we decide on) is sufficient. The UTS would also have to inform the kernel > of the user-level routines to use for event notification, so this would > probably be sufficient for marking a process as needing different > call/return conversions (SAs). It is probable that we will need a different syscall calling convension to handle teh async nature of the world. If we use a second syscall gate, we can intermix old and new system calls during development. > > I have a question. How do we manage kernel contexts in the kernel? > How many threads are allowed to be blocked in the kernel at any one > time? Each thread blocked in the kernel uses a resource (probably > some structure with a kernel register save area, a TAILQ/LIST entry > or two, etc), and this should be constrained in some way. Should > pthread_setconcurrency(3) adjust the number of kernel contexts > assigned to a process? each KSE has a 'struct thread' which includes a kernel stack and processor context saving space. it is linked back to a struct proc on a circular list. The struct procs describe "SUBPROCESSES" and are in turned grouped in some way to form a 'PROCESS' The more interesting question is "What do we do when we cannot allocate any more of these? (KSEs)" (either through limits or resource shortage). > > Dan Eischen > eischen@vigrid.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.9911131208050.21751-100000>