From owner-freebsd-arch Sun Nov 28 8:42:46 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 EA59614BE9 for ; Sun, 28 Nov 1999 08:42:31 -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 RAA24266 for ; Sun, 28 Nov 1999 17:42:28 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA58041 for freebsd-arch@freebsd.org; Sun, 28 Nov 1999 17:42:28 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id F38AE14BE9 for ; Sun, 28 Nov 1999 08:42:00 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id IAA44909; Sun, 28 Nov 1999 08:41:57 -0800 (PST) (envelope-from dillon) Date: Sun, 28 Nov 1999 08:41:57 -0800 (PST) From: Matthew Dillon Message-Id: <199911281641.IAA44909@apollo.backplane.com> To: Arun Sharma Cc: freebsd-arch@freebsd.org Subject: Re: Threads References: <199911241905.LAA20045@apollo.backplane.com> <14396.15070.190669.25400@avalon.east> <199911241941.LAA20231@apollo.backplane.com> <19991124212521.W301@sturm.canonware.com> <199911280338.TAA40637@apollo.backplane.com> <19991127205752.A7145@sharmas.dhs.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :current BSD scheduler. : :(a) schedcpu() is called every hz ticks. This requires locking the runqueues. : On a SMP system, all other processors are completely locked out. Clearly, : someone needs to redesign the system such that priorities get recomputed : in an event driven fashion. Uresh Vahalia's book (Ch 5.5.6) talks about : this. I think we are already operating under the assumption that the current scheduler must be rewritten, or at least significantly modified. Amoung other things we have to get rid of all the extra junk that is in assembler that could easily be C (I seem to recall someone actually working towards that goal, was any of that ever committed? It seemed pretty good). Ideas have already been put forth. For example, giving the scheduler its own lock (or locks) independant of the MP lock. :(b) If you want to implement processor binding, the implementation is simpler : with per cpu runqueues. A multi-queue implementation would scale better for this situation. I wouldn't go as far as to say that it would be necessarily easier from an implementation point of view. I think of it in these terms: You have a process which may have no binding restrictions, loose binding restrictions, or hard binding restrictions. Most of the thread support is going to be classified as having loose binding restrictons or none at all (i.e. a general purpose setup). Hard binding is easiest with multiple queues for obvious reasons, but loose/no binding is easiest with a single queue. From an implementation point of view. :(c) Although not a justification by itself, I remember reading that the most : recent version of AIX uses per cpu runqueues to scale better on SMP. : :On the other hand, implementing scheduler activations and SMP scaling :simultaneously would be too much of a change. It might be a good idea :to do one thing at a time. : : -Arun I'm thinking that it would be easier to augment the single run queue we currently have first and then redo it later after the rest of the system has been made more SMP aware. In regards to performance, right now the scheduler is the least of our worries. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message