Date: Sun, 28 Nov 1999 16:53:27 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Julian Elischer <julian@whistle.com> Cc: peter.jeremy@alcatel.com.au, freebsd-arch@freebsd.org Subject: Re: Threads stuff Message-ID: <199911290053.QAA47117@apollo.backplane.com> References: <Pine.BSF.4.10.9911281626180.544-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:I think there is confusion here..
:
:The way Dan and I have been discussing it (you need to go back and read
:the old mail) the process creates several thread classes. Thread classes
:can be bound to a CPU and can have different system priorities. They are
:implemted in FreeBSD by rfork()ing a new process (called a subprocess.
:The scheduler then assigns threads to the subprocess. Effectively
:assigning them to a class.
:if the class is "all threads herein run on CPU1" tehn you get what you
:want..
:Dan left of the "sub".
:
:Julian
Why assign classes to processes when you can assign classes to KSE's?
If you intend to have a UTS, the UTS must dynamically manage the
runnability of the KSE's anyway so there isn't any real need to group
them in their own rfork()'d processes.
Since the KSE is the kernel's scheduling entity, not a process, it
makes sense to concentrate the work in the KSE rather then complicate
matters by grouping classes with rfork(). This does not prevent us from
rfork()ing, it just makes rfork() unnecessary for thread management.
There are plenty of other reasons why one might want to rfork() that
have nothing to do with thread management so we obviously want to keep
that functionality.
If you concentrate the work in the KSE, the design becomes much, much
simpler.
-Matt
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?199911290053.QAA47117>