From owner-freebsd-arch Thu Nov 4 19:11: 2 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 3777114BF4 for ; Thu, 4 Nov 1999 19:10:59 -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 EAA08529 for ; Fri, 5 Nov 1999 04:10:42 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA96778 for freebsd-arch@freebsd.org; Fri, 5 Nov 1999 04:10:41 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 0EBE315858 for ; Thu, 4 Nov 1999 19:08:59 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt9.pcnet.net [206.105.29.83]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id WAA29629; Thu, 4 Nov 1999 22:03:52 -0500 (EST) Message-ID: <38224942.6447A8B2@vigrid.com> Date: Thu, 04 Nov 1999 22:04:34 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: rcarter@chomsky.Pinyon.ORG Cc: Amancio Hasty , Terry Lambert , julian@whistle.com, freebsd-arch@freebsd.org Subject: Re: Threads goals version III References: <19991105011623.CE5AD4D@chomsky.pinyon.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Russell L. Carter" wrote: > > %> One could argue that the program should be using a hybrid scheduling > %> class in the kernel in order to achieve this effect, rather than > %> having to have the idea that you would want to schedule seperate > %> kernel schedulable entities within one program. > % > %How to you propose to handle priorieties for different > %"thread thingies" --- "thread thingies" being a yet to > %be defined thread implementation. > % > > One uses pthread_*sched* routines to modify scheduling > attributes for individual threads. Whether or not those threads > can get process or system scope, as in the spec, or just process > scope, that is the question. > > If I groked Terry's first missive then the process should first > set scheduling attributes via sched_setscheduler, if it needs > something other than SCHED_OTHER (default per process scheduling). > I'm still studying whether or not this is good enough; i.e., can > individual threads in a process with a SCHED_FIFO or SCHED_RR > policies meet QoS goals, and does it provide the flexibility > needed by an application structured as Daniel's is. I don't think it does. I think under Terry's scheme, it wouldn't be possible to bind a thread to a KSE and place it in a different scheduler class. It would still be possible to run [user] threads in different scheduler classes without being bound to a KSE, but this wouldn't reserve a quantum in which the threads could execute. So if the application on the whole was at or near it's process limits, the threads in the real-time (or some other than the default) scheduler class wouldn't be able to run. You could make allowances for this situation and manage accounting differently for a process running under multiple scheduling classes, but it still seems simpler to allow (with correct privileges) system scope threads to be bound to KSEs with their own quantum. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message