Date: Mon, 2 Jul 2001 16:23:06 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Julian Elischer <julian@elischer.org> Cc: current@FreeBSD.ORG Subject: Re: RFC: Kernel thread system nomenclature. Message-ID: <Pine.SUN.3.91.1010702161515.12508A-100000@pcnet1.pcnet.com> In-Reply-To: <Pine.BSF.4.21.0107021319090.13213-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2 Jul 2001, Julian Elischer wrote: > > The time has come (now that we have a design) to assign names to the > various entities that will be created when we implement the > (current name) KSE code. > > I have already done initial work on this and have a system running with > the proc structure split into 4 parts. > > The names of these parts need to be fully decided and agreed upon now > while the changes are limited to 2 files :-) The next change requires > editing almost every file in the kernel. The KSE names were a temporary > measure to identify these while their functions were being decided. > > Here are the entities, a decription of what they do, and some suggested > names: > > 1) This structure 'owns' all the resources that are relavent to the > process. It owns the credentials, the VM space, the file desriptors, > (possibly the signal state), the parent process, the child processes > etc. etc. > > Suggested names: proc, task (others?) > > 2) The second structure owns the scheduling parameters. All scheduling > decisions are made according to information held in this structure. The is > by default one of these per each of the above (#1) structure. However the > threads library may make more should it wish to shedule some threads at a > different priority. Each of these competes with the weight of a process in > the system scope. In the case where there are not per-cpu run queues, THIS > would be put on the run queues. There may be between 1 and M of these > where M is the remaining rlimit on processes. (they count as processes > against the rlimits) > > Suggested names: schedblock (SB), > Kernel Schedulabale Entity Group (KSEG), > KSE (confusing but acurate), > SchedEntry, (SE?), > Process Schduling control block (pscb) I think Mike's point about not naming this kseg was good (to avoid confusion with kernel segment). scheduling param, schedparam? scheduling resource, schedres? > 3) The third structure is a container for running code contexts. The > concurrency of a MP machine can be exploited by having multiple of these > entities, each of which most be run on a different processor. With per-CPU > run queues, these would be on the queues, but the controling parameters > are inherrited from the 2nd structure. There may be between 1 and N (where > N is the number of processors) of these entities per each of the 2nd > structure type. Eligible contexts are run in either kernel or user mode > when this is scheduled. Each of these has a separate upcall context stored > for communication with the Userland scheduler. > > Suggested names: Kernel Schedulable Entity(KSE), > thread container(TC), > Scheduler Virtual processor(SVP), > Scheduler Slot(schedslot, ss?) > Thread processor (tp?) > > 4) The last entity is the 'kernel context' structure. > This contains the kernel stack for whatever thread of execution is being > run and is what is saved onto the sleep queues when a tread of execution > blocks. All the context needed to restart a thread is saved in this. > In the current system this information is stored in a combination of the > proc struct, the U area and the kernel stack. There can be an almost > unlimited (resource limited) number of these which would indicate > a large number of blocked syscalls. They are allocated to the #2 > structure and may run under more than one of the #3 entities during the > course of a syscall if there are context switches. they would have some > affinity to the last #3 they ran on for cache reasons, but conld be > switched to another #3 that is connected to the same #2 if it were idle. > > Suggested names: Thread Context Block (TCB) > Kernel Schedulabel Entity Context (KSEC) > Thread Context (TCTX) Other than renaming kseg to something else, the names we were using previously seemed OK. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" 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.1010702161515.12508A-100000>