From owner-freebsd-arch Fri Nov 5 15: 3:18 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 E4FAE14F54 for ; Fri, 5 Nov 1999 15:02:53 -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 AAA25554 for ; Sat, 6 Nov 1999 00:02:31 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA01620 for freebsd-arch@freebsd.org; Sat, 6 Nov 1999 00:02:28 +0100 (MET) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 8D3D0153B7 for ; Fri, 5 Nov 1999 15:01:25 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id QAA27871; Fri, 5 Nov 1999 16:01:07 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp01.primenet.com, id smtpdAAAj7ayl2; Fri Nov 5 16:00:53 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id QAA07809; Fri, 5 Nov 1999 16:00:33 -0700 (MST) From: Terry Lambert Message-Id: <199911052300.QAA07809@usr06.primenet.com> Subject: Re: Threads goals version III To: hasty@rah.star-gate.com (Amancio Hasty) Date: Fri, 5 Nov 1999 23:00:29 +0000 (GMT) Cc: tlambert@primenet.com, eischen@vigrid.com, julian@whistle.com, freebsd-arch@freebsd.org In-Reply-To: <199911050048.QAA49642@rah.star-gate.com> from "Amancio Hasty" at Nov 4, 99 04:48:32 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 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. You mean how will a user space scheduler implement the user space scheduling class that handles pthread_attr_setschedpolicy(3) calls? Or do you mean something deeper, such as "since I'm already thinking in terms of kernel threads, how will you let me set kernel scheduling policy for kernel threads, if there aren't any?". > What I am think is that for whatever reason there are applications > which want threads to be running at different priorities for instance > "Kaffe" wants or needs threads running at different priorities. That's no problem for any model, so long as you are talking threads priorities, rather than process priorities. If you are talking process priorities, well, then you're assuming something you shouldn't assume about the underlying implementation because POSIX doesn't give you permission to assume it. 8-). That's not to say that we might not want to implement a user space scheduler assist that can make modifications to which per CPU ready-to-run queue that kernel scheduling contexts take place in, but in my view migration between processors is a user space scheduler decision, based on what ready to run vs. where it ran last vs. what CPU is returning up into user space. I really can't see any other way that the kernel scheduler could know what would or would not be a cache bust, since it's so tightly bound to the particular program implementation; the kernel scheduler is a poor substitute for The Great Karnak. 8-). I'd really like to look at the kernel scheduler as nothing more than something that can hand out resources, and that a quantum is a resource, and that concurrent quanta are an artifact of SMP, and whether or not you get concurrent quanta is totally seperate from your policy decision about which thread in user space gets to run when you have a quantum in hand. Kind of like Linus (Lucy's brother, not Torvalds) and The Great Pumpkin: the quantum comes to visit a thread if it's in the most sincere process. Multiple CPU's bear the same resemblence to the quantum fairy as Elves bear to Santa Claus. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message