Date: Sat, 13 Nov 1999 18:45:37 -0500 From: "Daniel M. Eischen" <eischen@vigrid.com> To: Julian Elischer <julian@whistle.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: <382DF821.EE3DE564@vigrid.com> References: <Pine.BSF.4.10.9911131208050.21751-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote: > > > 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. Using SA, the UTS is informed when threads block and unblock (including page faults and preemption) in the kernel. As soon as the next "subprocess" is run/resumed, the UTS is notified of these events and can decide which thread to run next. > 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. Exactly the point of SA. An upcall is made to the UTS when the next sub- process is run, and the blocked threads state is passed as a parameter (somewhat simplified) on the stack of the activation. > THere are some questions tht come up from this: > > 1/ should there be one sub-process for each processor/priority > combination? No, it really is up to the UTS and the application to decide (which is then limited by limits/permissions in the kernel). From the user-land point of view, we have the POSIX/SSv2 pthread specs, and our own rtprio(2)/setpriority(2) commands. A userland program would create a PTHREAD_SCOPE_SYSTEM thread which would hopefully create an additional subprocess. At a later point in time, the same thread could change it's process priority, say using rtprio(2), which would change the priority of the subprocess in which it was executing. Additional threads could be created in the same way. > Maybe there is one scheduler 'activation' (hmm) per > subprocess? Reading the "Adding Scheduler Activations to Mach 3.0" paper, they say that there are always exactly as many SAs as there are physical processors. There are more SA stacks than SAs with an added system call to recycle them when they are no longer being used by the UTS. > 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? I agree - there is only ever one KSE per subprocess active, and possibly many blocked. I'd think that KSEs are assigned to the process as a whole (while free/blocked). It's up to the UTS to decide what thread to run/resume on what subprocess. A subprocess will need a link to the KSE that it is running, though. > > 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. OK, I can see how a different syscall gate might be useful 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. Currently, if I read the source correctly, a procs p_paddr (struct user) includes the kernel register save area and the kernel stack, and is swappable. If we start allowing more kernel contexts (KSEs), do we also want to allow them to be swappable? > 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). Tell the UTS when the limit has been reached, then block without SA notification when the limit has been exceeded? 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?382DF821.EE3DE564>