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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
