From owner-freebsd-arch Sat Nov 27 20:58: 7 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 3706314E74 for ; Sat, 27 Nov 1999 20:58:01 -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 FAA16864 for ; Sun, 28 Nov 1999 05:58:00 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA56260 for freebsd-arch@freebsd.org; Sun, 28 Nov 1999 05:58:00 +0100 (MET) Received: from c62443-a.frmt1.sfba.home.com (c62443-a.frmt1.sfba.home.com [24.0.69.165]) by hub.freebsd.org (Postfix) with ESMTP id 9EECF14E74 for ; Sat, 27 Nov 1999 20:57:53 -0800 (PST) (envelope-from adsharma@c62443-a.frmt1.sfba.home.com) Received: (from adsharma@localhost) by c62443-a.frmt1.sfba.home.com (8.9.3/8.9.3) id UAA07234; Sat, 27 Nov 1999 20:57:53 -0800 Date: Sat, 27 Nov 1999 20:57:52 -0800 From: Arun Sharma To: Matthew Dillon Cc: freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <19991127205752.A7145@sharmas.dhs.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <199911280338.TAA40637@apollo.backplane.com>; from Matthew Dillon on Sat, Nov 27, 1999 at 07:38:52PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Nov 27, 1999 at 07:38:52PM -0800, Matthew Dillon wrote: > > hmm. A very interesting article. They could well be correct - certainly > a single scheduling queue would become a problem if you have many > processors. I don't think there would be much contention with 4-8 cpu's, > at least not if we limit the lock to *just* the operation surrounding > the addition and removal of the KSE (using Julian's terminology) from > the queue. Also, this contention would *not* occur during a context > switch, only when a task is scheduled and descheduled. Locking of the runqueue is a problem, unless changes are made to the 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. (b) If you want to implement processor binding, the implementation is simpler with per cpu runqueues. (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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message