Date: Mon, 02 Jul 2001 14:20:52 -0700 From: Bakul Shah <bakul@bitblocks.com> To: Julian Elischer <julian@elischer.org> Cc: current@freebsd.org Subject: Re: RFC: Kernel thread system nomenclature. Message-ID: <200107022120.RAA06256@ajax.cnchost.com> In-Reply-To: Your message of "Mon, 02 Jul 2001 14:16:16 PDT." <Pine.BSF.4.21.0107021319090.13213-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Is there is an online description of what you guys decided at Usenix?
An xfig picture would be very helpful!
> 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?)
proc or process? Actually "domain" is more appropriate once
you can have multiple threads sharing the same VM.
> 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)
How about just schedule or schedule set? It is a
perfectly good noun! "control block" is just noise at this
point :-)
Seems like the old (Thoth) team concept. Can a thread
context belong to more than one of these?
> 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)
I am confused about #3 and #4. Sounds to me like #3 is a
runnable thread context and #4 is a sleeping/waiting thread
context. A runnable thread is bound to a processor. For
example, Given
processes A, B & C
processors X & Y,
Threads A1, A2, B1 are runnable; A3, B2, C1, C2 are waiting,
A1,A3 in one and A2 in another schedule set,
A1 and A2 are actually running, B1 is waiting for a processor
we have
3 #1 entities (A, B, C)
4 #2 entities ({A1,A3}, {A2}, {B1, B2}, {C1, C2})
3 #3 entities (A1, A2, B1)
4 #4 entities (A3, B2, C1, C2)
Correct? I am not sure how actually running threads are
distinguished from a runnable thread.
> 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.
But this would confuse future hackers. Appropriate names
really help even if it means moe editing now. I have found
that the process of coming up with the right names frequently
simplifies things.
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?200107022120.RAA06256>