From owner-freebsd-current Mon Jul 2 13:23:58 2001 Delivered-To: freebsd-current@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id AC02D37B403 for ; Mon, 2 Jul 2001 13:23:53 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id QAA14076; Mon, 2 Jul 2001 16:23:06 -0400 (EDT) Date: Mon, 2 Jul 2001 16:23:06 -0400 (EDT) From: Daniel Eischen To: Julian Elischer Cc: current@FreeBSD.ORG Subject: Re: RFC: Kernel thread system nomenclature. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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