Date: Sun, 28 Nov 1999 21:23:17 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Julian Elischer <julian@whistle.com> Cc: arch@freebsd.org Subject: Re: Threads stuff Message-ID: <199911290523.VAA59334@apollo.backplane.com> References: <Pine.BSF.4.10.9911282059000.544-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:> This seems like an added unnecessary complication that would be
:> difficult to scale dynamically to different topologies. Or, put another
:> way, the burden of knowledge is much greater with this scheme then with
:> other schemes.
:
:Think of the subprocs as "virtual processors" (your terminology)
:
:you would have one for each processor for maximum parallelism, but
:posibly a couple extra if you wanted a virtual processor that
:was to run at a higher priority
:...
:> active) threads do not need KSE's associated with them if they are not
:> in the midst of a system call.
:
:By hangling KSEs and threads off virtual procesors (rforked procs) you
:can do thread classes, which is one of the requirements we came to in
:the requirements phase. Subprocesses can have some processor affinity,
:and they have system-wide priority.
I just don't see it. You can do thread classes anyway, you don't
have to put them under a 'process' umbrella. In fact, it seems
to me that it would not be desireable to do so because it would
mean that the UTS would have to schedule across process boundries
(though not an MMU boundry) to attain maximum efficiency for the
default threading class.
A better solution would simply be to have a single process and give
the kernel the ability to schedule threads to processors via their
KSE's. The UTS can still setup whatever thread classes it likes,
and can still control the scheduling of KSE's, but it would not
need to dynamically create and delete process contexts on top of that.
Additionally, the kernel's scheduler would only have to deal with KSE's
rather then have to deal with processes + KSEs, and kernel threads would
simply be KSE's associated with a dummy kernel 'process', again without
having to write special code. Kernel interrupts would be able to do
the same -- run the interrupt in a KSE and still attain maximum
parallelism.
And the kernel can place the threads associated with the process into
a larger scheduling whole without having to special-case the priority
calculations that occur when you start splitting things into separate
processes. If you want a higher aggregate priority, you assign the
process a higher priority no matter how many threads there are and no
matter which scheduling class the threads are placed in relative to
each other. You can *still* rfork() if you want, but the reasons for
doing so become more deterministic then 'trying to simulate multiple
cpu's'.
All four mechanisms can be implemented by having the kernel scheduler
deal only with KSE's. That's (1) one implementation handling four
different mechanisms.
If we do it your way we wind up writing three times the amount of code
to deal with three different special cases, and that's assuming that
kernel threads and interrupt threads can be folded together into the
same entity. I see no advantage to doing things that way and I see
no advantage to creating such a high level of 'base' complexity.
-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?199911290523.VAA59334>