Date: Sat, 20 Nov 1999 21:20:40 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: Sean Eric Fagan <sef@kithrup.com> Cc: freebsd-arch@freebsd.org Subject: Re: Threads vs ps Message-ID: <Pine.BSF.4.10.9911202052350.6767-100000@current1.whistle.com> In-Reply-To: <199911210450.UAA23210@kithrup.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 20 Nov 1999, Sean Eric Fagan wrote:
>
> Let me rephrase it... what, exactly, _is_ a process? To me, a process
> is an individual, kernel-schedulable entity.
>
> As such, I would expect to have each (current-model) process-id be
> analogous to a (future-model) thread-id. So a "process" in the
> current model would be called a "thread group" in the new model.
>
> Something like that.
>
> >The registers are per thread, not per process, so you need eactly what you
> >say below.
> >> I could envision seeing /proc/pid/threads/{0,1,2,...,n}/{regs,status,etc};
>
> That is, I think, doable. I'll have to think a bit about it -- the hardest
> part is identifying via inode. But we have 32 bits, at least, to play with
> :).
Don't forget that we have already decided that threads (or Usre Level
threads (ULT) are invisible from outside that process without incestuous
knowledge of the particular UTS (User Threads Scheduler) that is running
on that process (there may be many to choose from). The lowest level you
can see from outside is the KSE (Kerrnel Schedulabel Entity). ULTs may
migrate from one KSE to another (and in fact probably will in an SMP
world). KSEs may be bound to a particular subprocess/processor
intersection. Subprocesses have prioroties, KSE's do not. They inherrit
the priority from their subprocess while they are runnable.
i.e. for a particular process, running under 2 way SMP:
B = blocked KSE
R = Runnable KSE
X = Executing KSE
| subproc 1 | subproc 2 | subproc 3 |
| priority= 1 | prio = 2 | prio = 2 |
------------------------------------------------------------------------
CPU1 | BBX | | BBBBBR |
| | | |
------------------------------------------------------------------------
CPU2 | | BBRX | |
| | | |
------------------------------------------------------------------------
| | | |
Whether a KSE can be considered to belong to any particular
subprocess when it is blocked is another question. As blocked processes in
UNIX come back to life with a raised process priority, this may indicate
that the UTS needs to know about this so that is can schedule threads onto
the newly returned high priority subprocess. there are real-time
repercussions we need to think about.
I drew all this out on a whiteboard the other day with terry
We decided that subprocesses were on the run queue, but that KSEs were on
the sleep queue. Each CPU has a 'curproc' that points to the
currently running subprocess. I think the differnce was that the
subprocess could remain on the run queue and be a curpoc..
hmm I can't remember how it all went now..
aarghh, terry wrote it all down
hopefully he hasn't lost it :-)
Julian
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" 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.10.9911202052350.6767-100000>