From owner-freebsd-arch Tue Nov 30 14:27:42 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 E414F14CFF for ; Tue, 30 Nov 1999 14:27:39 -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 XAA12089 for ; Tue, 30 Nov 1999 23:27:38 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA73348 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 23:27:38 +0100 (MET) Received: from canonware.com (canonware.com [207.20.242.18]) by hub.freebsd.org (Postfix) with SMTP id 96D7F14CFF for ; Tue, 30 Nov 1999 14:27:22 -0800 (PST) (envelope-from jasone@canonware.com) Received: (qmail 37843 invoked by uid 1001); 30 Nov 1999 22:25:55 -0000 Date: Tue, 30 Nov 1999 14:25:55 -0800 From: Jason Evans To: Matthew Dillon Cc: freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <19991130142555.F301@sturm.canonware.com> 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 1.0i In-Reply-To: <199911280338.TAA40637@apollo.backplane.com>; from dillon@apollo.backplane.com 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: > :Until reading about DEC's threading efforts > :(http://www.digital.com/info/DTJF03/DTJF03SC.TXT) a few days ago, I would > :have agreed with you. However, that paper makes some very valid arguments > :for needing multiple scheduling queues. The paper is very worthwhile > :reading. > : > :Jason > > 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. It seems to me that there would be some significant negative impacts due to cache sloshing, since all CPUs would need to modify the same scheduling queue often enough for it to be a big deal. I agree that the lock contention would be insignificant, but the caching issues seem real. Maybe I don't completely understand what you're proposing. > Another possible solution to the single-queue case is to not lock the > queue for sleep/wakeup operations but to instead shared-lock the > surrounding task(s). This would allow multiple cpu's to add and remove > tasks from different parts of a single queue simultaniously. I've > never done this myself -- it's never seemed worthwhile. Hmm, this idea could have some merit. We should keep it in mind. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message