Date: Mon, 2 Jul 2001 14:16:16 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: current@freebsd.org Subject: RFC: Kernel thread system nomenclature. Message-ID: <Pine.BSF.4.21.0107021319090.13213-100000@InterJet.elischer.org>
next in thread | raw e-mail | index | archive | help
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 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.BSF.4.21.0107021319090.13213-100000>