Date: Sun, 28 Nov 1999 21:37:39 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Julian Elischer <julian@whistle.com>, arch@freebsd.org Subject: Re: Threads stuff Message-ID: <199911290537.VAA61862@apollo.backplane.com> References: <Pine.BSF.4.10.9911282059000.544-100000@current1.whistle.com> <199911290523.VAA59334@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Let me give you an example of how it would work if KSEs were the kernel
scheduling entity instead of processes.
(1) The UTS wants to run threads in a FIFO.
- UTS schedules one thread at a time with the kernel. That is,
it deschedules the current thread and schedules a new one. FIFO
operation is achieved.
(2) The UTS wants to run several threads in parallel
- UTS schedules several threads at a time with the kernel. For
example, the UTS can decide to schedule two threads with the
kernel (not deschedule the first one after scheduling the second
one).
- UTS is thus able to simulate N cpu's, a 'virtual cpu environment'
without having to run through loops with rfork() and exit().
- kernel memory and process 'clutter' is minimized. There is still
only one process shown in the ps (or at least the base ps).
(3) The UTS wants to simulate prioritized software interrupts using
threads.
- UTS simply deschedules the thread being interrupted and schedules
the interrupting thread, and vise-versa on return.
(4) The UTS wants to simulate a multi-priority RR queue.
- UTS simply schedules all threads at the highest priority all
at once and ensures that threads at lower priorities are
descheduled.
You see? It's easy. If you try to do this under a multiple-process
umbrella using rfork() and enforce serialization on a process-by-process
basis, you complicate matters greatly. For example, take the last
algorithm -- N equi-priority threads need to be run with maximum
parallelism. In the rfork() case the UTS code becomes much more complex
then simply telling the kernel to 'go' with all N threads. The UTS must
manage the spread across the virtual cpu's as well and must have direct
knowledge of the number of cpu's in the system on top of that.
But if the KSE is the schedulable entity and the UTS is simply trying
to simulate N cpu's (where N can be anything -- including large numbers
like 10 or 20), the UTS simply tells the kernel to 'go' for all N
threads and lets the kernel deal with the conversion to actual physical
cpu's.
Similarly, reserving a physical cpu is also trivial. In this case just
as trivial as reserving a 'virtual' cpu.
A whole lot of code becomes a whole lot less complex if the KSE is
the schedulable entity rather then the struct proc.
-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?199911290537.VAA61862>