Re: RFC: Kernel thread system nomenclature.
John Baldwin wrote: One other note. #2 is conceptually a related group of #4's, so I think it's name should reflect that. (It's view as a group of #4's is more important than as being a part of #1.) So, if you go with lwp (yuck) for #4, #2 should be lwpgrp or some such. I still think lwp's overloaded nomenclature is a reason to stay away from it. *shrug* I agree. SunOS 4.1.3 had a liblwp, which was basically a user space threading library. Solaris/SVR4 pushes this into the kernel because of SMP scaling (if the only tool you have is threads, everything looks like it's solved by threads). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RFC: Kernel thread system nomenclature.
On 2001-Jul-06 18:14:03 -0700, Julian Elischer [EMAIL PROTECTED] wrote: #3 ??? (thread carrier (spindle? :-)) or thread-processor A spindle is a physical disk drive (or at least independent head assembly) - I/O rates are associated with spindles rather than [virtual/RAID] disks. If we're going to use the sewing analogy, maybe bobbin :-). Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RFC: Kernel thread system nomenclature.
John Baldwin wrote: #3struct upctx (upcall-context), virtcpu, thrdslot (thread slot) #4struct lwp(decided) usually the 'lwp' will be passed around so diffs to NetBSD will be minimalised. One thing to note is that as Vahalia (sp?) points out, lwp on SVR4 and Solaris is actually #3 (a virtual CPU) where as lwp on SunOS is a user-thread. Unfortunately, I think by using overloaded terms you are going to confuse people who come into the project from different backgrounds. I would try and stay with non-ambiguous names if possible. Virtual CPUs are a very bad idea. The main reason SVR4 and Solaris threading didn't scale well from day one is the virtual CPU approach. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RFC: Kernel thread system nomenclature.
Daniel Eischen wrote: On Fri, 6 Jul 2001, Peter Wemm wrote: Julian Elischer wrote: On Fri, 6 Jul 2001, Daniel Eischen wrote: -proc- -thrgrp- -thr- -thrctx- interesting, though the thrctx maps most closely to a userland thread. there may be many threads running on each #3. IMHO, I like this less than kse/kseg/ksec/proc. Remember.. these are not thread specific.. they can be used to implement aio etc as well. The KSE paper's definitions of things are pretty clear. If we're not going to use something netbsd compatable, then IMHO we should stick to the design paper. That was my first thought also ;-) The only variation that I think I'd find appealing would be to try and make the kseg/ksec difference stand out more. ksegrp/ksectx is less likely to be confused at a casual glance. I'm not really sure that we can use the 'struct lwp' name in a compatable way with NetBSD. It would be even worse if we both had 'struct lwp' but ours was different to theirs. NetBSD doesn't (yet) have an idea of a KSE group. We could just replace our usage of KSE with LWP: proc- lwpgrp- lwp- lwpctx- If NetBSD ever folded in our KSE group support, wouldn't that be the most compatible? heh.. unlikely as to which (#4 or #3) is the lwp, I think that #4 is the lwp as it is what is put on the sleep queue, and it is what has the kernel stack and context to be restarted. Their equivalent to #3 is a couple of fields in the 'sadata' struct and the 'struct sa' that is passed around. The define a 'per process' upcall location and have a predefined number of stacks passed to the kernel to use on these upcalls. We define a separate preloaded context for each #3 to come back on. They directly schedule all lwps on the run queue, thereby giving them all 'process' weight by default. We do it via #2, which allows us to keep them fairer (if we want). ... etc... Look for these in particular: Index: sys/sys/lwp.h Index: sys/sys/proc.h Index: sys/sys/sa.h Index: sys/sys/savar.h yep looked at them. interesting but predictable if you've read the sa paper. I still don't understand the solaris lwp mode though... If we dont do similar structure member naming, then there is no point using the same structure names as that will just increase the confusion. I think that their lwp and or #4 are really pretty similar in a lot of ways but as you suggest, maybe not similar enough to keep the name the same. NetBSD's structure is different too.. They have implelemted both Solaris-style LWP's and SA's over the top of the same low level entity. I like that they use a ucontext_t for storing the context also. Julian, can we please do the same? We'll probably also need to use a spare slot in ucontext/mcontext for a flags word (floating point register validity?). I was always planning to use one, the only difference is where it is stored.. We bypass the need to have a trampoline by knowing in advance where to copy out the ucontext to. We can also report back many blocked calls at once and many completed ones at the same time. The ucontext is stored directly back to user space rather than copied to the stack, and then copied to the thread storage.. The thread storage contains a ucontext. They use it indirectly, while we use it directly. we COULD put it on the stack like they do, but I think our idea is more flexible. ok, so to the names.. #1 proc #2 ksegrp #3 kse #4 ksectx shorter abreviations: ip-p_x kg-kg_ ke-ke_ kc-kc_ (this is what Jasone proposed on my original suggestions.) but at least this way I won't get grief on it and it also matches what I've already coded :-) -- Dan Eischen -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +--x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RFC: Kernel thread system nomenclature.
Peter Wemm wrote: Jason Evans wrote: On Mon, Jul 02, 2001 at 02:16:16PM -0700, Julian Elischer wrote: [...] I think there is a clear argument for #1 to be "struct proc". I don't much care what #2, #3, and #4 are called. I am of the rather strong opinion that calling #3/#4 "struct proc" is a bad idea in the long run. Yes, it would reduce the diffs, but it would be terribly confusing to those who weren't versed with the development history of KSEs. Also keep in mind that netbsd use 'struct lwp *' for #3/#4 (SA has these combined into one entity). If there is an easy way to not be gratuitously different I think it would be worth it. Also comments by several others.. Ok so here's how it looks to me now: (still not final) #1struct proc (decided) #2struct schedgrp ,lpwg (lwp-group), prigrp (priority-group) subproc (subprocess) #3struct upctx (upcall-context), virtcpu, thrdslot (thread slot) #4struct lwp(decided) usually the 'lwp' will be passed around so diffs to NetBSD will be minimalised. my favourites are: proc, subproc, lwcpu, lwp lwps are parcelled out to lwcpus to run when the appropriate subproc is scheduled. -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +--x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RFC: Kernel thread system nomenclature.
that reminds me.. The reason I want to work out the names now is because I have a system up and running with the process structure split into these pieces and I wan teh names finalised before I take the next step which involves editing almost every kernel file. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RFC: Kernel thread system nomenclature.
On 06-Jul-01 Julian Elischer wrote: Peter Wemm wrote: Jason Evans wrote: On Mon, Jul 02, 2001 at 02:16:16PM -0700, Julian Elischer wrote: [...] I think there is a clear argument for #1 to be struct proc. I don't much care what #2, #3, and #4 are called. I am of the rather strong opinion that calling #3/#4 struct proc is a bad idea in the long run. Yes, it would reduce the diffs, but it would be terribly confusing to those who weren't versed with the development history of KSEs. Also keep in mind that netbsd use 'struct lwp *' for #3/#4 (SA has these combined into one entity). If there is an easy way to not be gratuitously different I think it would be worth it. Also comments by several others.. Ok so here's how it looks to me now: (still not final) #1struct proc (decided) #2struct schedgrp ,lpwg (lwp-group), prigrp (priority-group) subproc (subprocess) #3struct upctx (upcall-context), virtcpu, thrdslot (thread slot) #4struct lwp(decided) usually the 'lwp' will be passed around so diffs to NetBSD will be minimalised. my favourites are: proc, subproc, lwcpu, lwp lwps are parcelled out to lwcpus to run when the appropriate subproc is scheduled. One other note. #2 is conceptually a related group of #4's, so I think it's name should reflect that. (It's view as a group of #4's is more important than as being a part of #1.) So, if you go with lwp (yuck) for #4, #2 should be lwpgrp or some such. I still think lwp's overloaded nomenclature is a reason to stay away from it. *shrug* -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RFC: Kernel thread system nomenclature.
On Fri, 6 Jul 2001, John Baldwin wrote: my favourites are: proc, subproc, lwcpu, lwp lwps are parcelled out to lwcpus to run when the appropriate subproc is scheduled. One other note. #2 is conceptually a related group of #4's, so I think it's name should reflect that. (It's view as a group of #4's is more important than as being a part of #1.) So, if you go with lwp (yuck) for #4, #2 should be lwpgrp or some such. I still think lwp's overloaded nomenclature is a reason to stay away from it. *shrug* As peter pointe out, NetBSD use lwp as a combination of #3 and #4 (in fact they are mostly #4.. as they include a kernel stack I think) (hmm need to look at their definitions again) I think that an lwp can block. That makes it #4 definitly. unless we call the 'threads' ? that would give: #1 proc #2 threadclass #3 ??? (thread carrier (spindle? :-)) or thread-processor #4 thread the 'thread' is a path through code combined with a context. it proceeds along this path when loaded into a thread-processor or an execution-slot or whatever we want to call #3. (i.e. it's scheduled). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RFC: Kernel thread system nomenclature.
On 07-Jul-01 Julian Elischer wrote: that reminds me.. The reason I want to work out the names now is because I have a system up and running with the process structure split into these pieces and I wan teh names finalised before I take the next step which involves editing almost every kernel file. Definitely. Now is the time to do this. :) -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RFC: Kernel thread system nomenclature.
On 07-Jul-01 Julian Elischer wrote: On Fri, 6 Jul 2001, John Baldwin wrote: my favourites are: proc, subproc, lwcpu, lwp lwps are parcelled out to lwcpus to run when the appropriate subproc is scheduled. One other note. #2 is conceptually a related group of #4's, so I think it's name should reflect that. (It's view as a group of #4's is more important than as being a part of #1.) So, if you go with lwp (yuck) for #4, #2 should be lwpgrp or some such. I still think lwp's overloaded nomenclature is a reason to stay away from it. *shrug* As peter pointe out, NetBSD use lwp as a combination of #3 and #4 (in fact they are mostly #4.. as they include a kernel stack I think) (hmm need to look at their definitions again) I think that an lwp can block. That makes it #4 definitly. unless we call the 'threads' ? I like 'thread' for #4 personally, as I think it's what most people think of when they think of an execution context. that would give: #1 proc #2 threadclass #3 ??? (thread carrier (spindle? :-)) or thread-processor #4 thread the 'thread' is a path through code combined with a context. it proceeds along this path when loaded into a thread-processor or an execution-slot or whatever we want to call #3. (i.e. it's scheduled). Sounds good to me. Just make #3 make sense. :) I would vote for simple names over more complex ones just to make it easier to understand. curproc/curthread/curwhatever and other process-related things get used all over the kernel (except that it's fairly rare in drivers) so lots of people are going to have to use this scheme in the future. More so than if the internals of the VM were renamed, for example. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RFC: Kernel thread system nomenclature.
On Fri, 6 Jul 2001, Julian Elischer wrote: On Fri, 6 Jul 2001, John Baldwin wrote: One other note. #2 is conceptually a related group of #4's, so I think it's name should reflect that. (It's view as a group of #4's is more important than as being a part of #1.) So, if you go with lwp (yuck) for #4, #2 should be lwpgrp or some such. I still think lwp's overloaded nomenclature is a reason to stay away from it. *shrug* As peter pointe out, NetBSD use lwp as a combination of #3 and #4 (in fact they are mostly #4.. as they include a kernel stack I think) (hmm need to look at their definitions again) I think that an lwp can block. That makes it #4 definitly. unless we call the 'threads' ? that would give: #1 proc #2 threadclass #3 ??? (thread carrier (spindle? :-)) or thread-processor #4 thread the 'thread' is a path through code combined with a context. it proceeds along this path when loaded into a thread-processor or an execution-slot or whatever we want to call #3. (i.e. it's scheduled). I think #3 should be thread and #4 should be thread context (and #2 should be thread [scheduling] group). -thrgrp- -thr- -thrctx- -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RFC: Kernel thread system nomenclature.
On Fri, 6 Jul 2001, Daniel Eischen wrote: -proc- -thrgrp- -thr- -thrctx- interesting, though the thrctx maps most closely to a userland thread. there may be many threads running on each #3. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RFC: Kernel thread system nomenclature.
Julian Elischer wrote:
On Fri, 6 Jul 2001, Daniel Eischen wrote:
-proc-
-thrgrp-
-thr-
-thrctx-
interesting, though the thrctx maps most closely to a userland thread.
there may be many threads running on each #3.
IMHO, I like this less than kse/kseg/ksec/proc. Remember.. these are
not thread specific.. they can be used to implement aio etc as well.
The KSE paper's definitions of things are pretty clear. If we're not
going to use something netbsd compatable, then IMHO we should stick to
the design paper.
The only variation that I think I'd find appealing would be to try
and make the kseg/ksec difference stand out more. ksegrp/ksectx is less
likely to be confused at a casual glance.
I'm not really sure that we can use the 'struct lwp' name in a compatable
way with NetBSD. It would be even worse if we both had 'struct lwp'
but ours was different to theirs.
Have a good look at: http://people.freebsd.org/~peter/sa1.diff
This was generated from NetBSD's netbsd_sa branch a while ago.
It shows the linkage between struct proc and struct lwp pretty clearly.
eg:
-intsys_exit(struct proc *, void *, register_t *);
+intsys_exit(struct lwp *, void *, register_t *);
...
int
-sys_execve(struct proc *p, void *v, register_t *retval)
+sys_execve(struct lwp *l, void *v, register_t *retval)
{
struct sys_execve_args /* {
syscallarg(const char *)path;
syscallarg(char * const *) argp;
@@ -315,8 +316,9 @@
int error, i;
struct exec_package pack;
struct nameidatanid;
struct vattrattr;
+ struct proc *p;
struct ucred*cred;
char*argp;
char * const*cpp;
char*dp, *sp;
@@ -328,8 +330,9 @@
char**tmpfap;
int szsigcode;
struct exec_vmcmd *base_vcp;
+ p = l-l_proc;
cred = p-p_ucred;
base_vcp = NULL;
/*
* Init the namei data to point the file user's program name.
... etc...
Look for these in particular:
Index: sys/sys/lwp.h
Index: sys/sys/proc.h
Index: sys/sys/sa.h
Index: sys/sys/savar.h
If we dont do similar structure member naming, then there is no point
using the same structure names as that will just increase the confusion.
NetBSD's structure is different too.. They have implelemted both
Solaris-style LWP's and SA's over the top of the same low level entity.
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: RFC: Kernel thread system nomenclature.
On Fri, 6 Jul 2001, Peter Wemm wrote: Julian Elischer wrote: On Fri, 6 Jul 2001, Daniel Eischen wrote: -proc- -thrgrp- -thr- -thrctx- interesting, though the thrctx maps most closely to a userland thread. there may be many threads running on each #3. IMHO, I like this less than kse/kseg/ksec/proc. Remember.. these are not thread specific.. they can be used to implement aio etc as well. The KSE paper's definitions of things are pretty clear. If we're not going to use something netbsd compatable, then IMHO we should stick to the design paper. That was my first thought also ;-) The only variation that I think I'd find appealing would be to try and make the kseg/ksec difference stand out more. ksegrp/ksectx is less likely to be confused at a casual glance. I'm not really sure that we can use the 'struct lwp' name in a compatable way with NetBSD. It would be even worse if we both had 'struct lwp' but ours was different to theirs. NetBSD doesn't (yet) have an idea of a KSE group. We could just replace our usage of KSE with LWP: proc- lwpgrp- lwp- lwpctx- If NetBSD ever folded in our KSE group support, wouldn't that be the most compatible? ... etc... Look for these in particular: Index: sys/sys/lwp.h Index: sys/sys/proc.h Index: sys/sys/sa.h Index: sys/sys/savar.h If we dont do similar structure member naming, then there is no point using the same structure names as that will just increase the confusion. NetBSD's structure is different too.. They have implelemted both Solaris-style LWP's and SA's over the top of the same low level entity. I like that they use a ucontext_t for storing the context also. Julian, can we please do the same? We'll probably also need to use a spare slot in ucontext/mcontext for a flags word (floating point register validity?). -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RFC: Kernel thread system nomenclature.
Jason Evans wrote: On Mon, Jul 02, 2001 at 02:16:16PM -0700, Julian Elischer wrote: 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. I think there is a clear argument for #1 to be struct proc. I don't much care what #2, #3, and #4 are called. I am of the rather strong opinion that calling #3/#4 struct proc is a bad idea in the long run. Yes, it would reduce the diffs, but it would be terribly confusing to those who weren't versed with the development history of KSEs. Also keep in mind that netbsd use 'struct lwp *' for #3/#4 (SA has these combined into one entity). If there is an easy way to not be gratuitously different I think it would be worth it. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RFC: Kernel thread system nomenclature.
On 2001-Jul-02 14:16:16 -0700, Julian Elischer [EMAIL PROTECTED] 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'm reasonably sure that there's prior art here. What do other OS's call these entities? Our naming convention should at least be not inconsistent, and preferably consistent with other implementations. This is especially true for related implementations (BSDi and *BSD - if any of them have gone this path). This affects code portability between the *BSDs, developers who use multiple Unix variants as well as 3rd party vendors. 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.. :-). IMHO, what we call #4 has the biggest impact (extending to what we can reasonable call #1). As I see it, the tradeoffs are: Keeping the same name: + Everyone is familiar with it - The entity it references is no longer a `process' and hence the name is no longer descriptive. Changing the name: + The chosen name would be descriptive of its contents. - Massive diffs required (I count ~5200 references in 648 files in /sys and there are more references in userland). Personally, I'd prefer to see struct proc renamed to reflect its new role as a thread context. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RFC: Kernel thread system nomenclature.
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
Re: RFC: Kernel thread system nomenclature.
Oh what a bikeshed you've begun. :) * Julian Elischer [EMAIL PROTECTED] [010702 14:39] 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?) Proc, this keeps the unix convention, a task is confusing, at least to me because afaik in Linux a task is actually a thread. Keeping it as proc will also require fewer changes to the code. :) 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) Scheduling control block. Remove 'Process' because as far as I understand it, it's not really a process, it's a group of threads. 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?) I think thread container makes the most sense. 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) thread/curthread, if you think about it, this is what it boils down to at the most basic level and therefore keeps the terminology simple. 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
Re: RFC: Kernel thread system nomenclature.
On Mon, 2 Jul 2001, Alfred Perlstein wrote: Oh what a bikeshed you've begun. :) Proc, this keeps the unix convention, a task is confusing, at least to me because afaik in Linux a task is actually a thread. Keeping it as proc will also require fewer changes to the code. :) Actually this would REDUCE teh size of the change.. MOST of the proc pointers will be changeing to #4 whatever that becomes. calling THAT proc would be the easiest :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RFC: Kernel thread system nomenclature.
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
Re: RFC: Kernel thread system nomenclature.
On Mon, 2 Jul 2001, Alfred Perlstein wrote: Scheduling control block. Remove 'Process' because as far as I understand it, it's not really a process, it's a group of threads. SCB is SCSI Command Block. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
