From owner-freebsd-arch Sat Dec 11 11:29:11 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 1218414A2A for ; Sat, 11 Dec 1999 11:29:04 -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 UAA16064 for ; Sat, 11 Dec 1999 20:28:56 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA45911 for freebsd-arch@freebsd.org; Sat, 11 Dec 1999 20:28:56 +0100 (MET) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 9766714D16 for ; Sat, 11 Dec 1999 11:28:47 -0800 (PST) (envelope-from rcarter@pinyon.org) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id MAA06031; Sat, 11 Dec 1999 12:28:31 -0700 (MST) Received: from ip-83-008.prc.primenet.com(207.218.83.8), claiming to be "pinyon.org" via SMTP by smtp01.primenet.com, id smtpdAAA2faGJl; Sat Dec 11 12:28:23 1999 Received: from chomsky.Pinyon.ORG (localhost [127.0.0.1]) by pinyon.org (Postfix) with ESMTP id 4C7504A; Sat, 11 Dec 1999 12:27:42 -0700 (MST) X-Mailer: exmh version 2.1.0 09/18/1999 To: nate@mt.sri.com (Nate Williams) Cc: Chuck Robey , Arun Sharma , freebsd-arch@freebsd.org, rcarter@pinyon.org Subject: Re: Thread scheduling In-Reply-To: Message from Nate Williams of "Fri, 10 Dec 1999 21:55:29 MST." <199912110455.VAA24095@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 11 Dec 1999 12:27:42 -0700 From: "Russell L. Carter" Message-Id: <19991211192742.4C7504A@pinyon.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG %> Not a guarantee, but would it be a good thing to have them %> "co-scheduled" (or a bias towards that likelihood). % %But, I can't see any advantage to have them co-scheduled. In the realm of parallel numerical algorithms there are quite a lot of practical algorithms that require cross "task" communication and to the extent that the "tasks" are not executed in roughly synchronous fashion so that their intricate communication schedules may be carried out more or less non-blocking then the algorithm suffers from disastrous multicpu inefficiency. Typically, these "tasks" share miniscule amounts of data, but any "waiting" is fatal to scalable throughput. Hence the development of the "gang scheduling" notion that Arun referred to. This is most highly refined and effectively implemented in Cray UNICOS systems. But I wouldn't worry about it. It's a small slice of the whole customer pie, and causes indigestion for my particular fetish, which is independently schedulable (ala POSIX) threads capable of meeting QOS guarantees. :-) Russell % % % %Nate % To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message