Date: Fri, 06 Jul 2001 23:48:48 -0700 From: Julian Elischer <julian@elischer.org> To: Daniel Eischen <eischen@vigrid.com> Cc: Peter Wemm <peter@wemm.org>, John Baldwin <jhb@FreeBSD.ORG>, current@FreeBSD.ORG, Jason Evans <jasone@canonware.com> Subject: Re: RFC: Kernel thread system nomenclature. Message-ID: <3B46B0D0.413DFEA5@elischer.org> References: <Pine.SUN.3.91.1010707002247.25592A-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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_xxxxx
kg->kg_xxxx
ke->ke_xxxx
kc->kc_xxxx
(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
| / \ julian@elischer.org +------>x USA \ a very strange
| ( OZ ) \___ ___ | country !
+- X_.---._/ presently in San Francisco \_/ \\
v
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?3B46B0D0.413DFEA5>