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)
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)
Any more suggestions are most welcome! (but seeing as how I'm doing the
code I will select as I see fit at the end of the discussion.
Almost all of the current 'proc' pointers being passed around the system
in syscalls will be changed to the #4 item. In addition, most accesses to
curproc would point to a curthread (curr-#4) or a curr#3, so the names
selected will be used a lot.
The exctent of these edits almost makes it worthwhile to call the #4 item
'struct proc' as the size of the diff would be MASSIVLY reduced.. :-).
(everyhting to do with sleeping, blocking, and waking up would
avoid changes, and everywhere a syscall passes down "struct proc *p"
would avoid changes.
Julian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
