From owner-freebsd-arch Sun Nov 28 21:23:27 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 2E9B614A1E for ; Sun, 28 Nov 1999 21:23:24 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id GAA09468 for ; Mon, 29 Nov 1999 06:23:24 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA61649 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 06:23:23 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 54A4414A1E for ; Sun, 28 Nov 1999 21:23:18 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id VAA59334; Sun, 28 Nov 1999 21:23:17 -0800 (PST) (envelope-from dillon) Date: Sun, 28 Nov 1999 21:23:17 -0800 (PST) From: Matthew Dillon Message-Id: <199911290523.VAA59334@apollo.backplane.com> To: Julian Elischer Cc: arch@freebsd.org Subject: Re: Threads stuff References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> 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