From owner-freebsd-arch Sun Nov 28 17:19:58 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 A6D90153FB for ; Sun, 28 Nov 1999 17:19:55 -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 CAA01864 for ; Mon, 29 Nov 1999 02:19:54 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA60688 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 02:19:54 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id A6F32153FB for ; Sun, 28 Nov 1999 16:53:28 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA47117; Sun, 28 Nov 1999 16:53:27 -0800 (PST) (envelope-from dillon) Date: Sun, 28 Nov 1999 16:53:27 -0800 (PST) From: Matthew Dillon Message-Id: <199911290053.QAA47117@apollo.backplane.com> To: Julian Elischer Cc: peter.jeremy@alcatel.com.au, freebsd-arch@freebsd.org Subject: Re: Threads stuff References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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