From owner-freebsd-arch Wed May 17 10:35:24 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 1B32F37BBC7 for ; Wed, 17 May 2000 10:35:16 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id KAA13575; Wed, 17 May 2000 10:34:36 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpdAAAynaqFA; Wed May 17 10:34:29 2000 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id KAA06172; Wed, 17 May 2000 10:35:03 -0700 (MST) From: Terry Lambert Message-Id: <200005171735.KAA06172@usr05.primenet.com> Subject: Re: A new api for asynchronous task execution To: cp@bsdi.com (Chuck Paterson) Date: Wed, 17 May 2000 17:35:02 +0000 (GMT) Cc: dfr@nlsystems.com (Doug Rabson), arch@FreeBSD.ORG In-Reply-To: <200005132342.RAA01739@berserker.bsdi.com> from "Chuck Paterson" at May 13, 2000 05:42:23 PM X-Mailer: ELM [version 2.5 PL2] 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 > }The system defines specific implementations of queues which are drained at > }particular times (initially I have defined one using SWI). I want to make > }it as easy as possible to define different lightweight queues for various > }types of work. The 'enqueue' function pointer in the taskqueue structure > }defines the run policy for the queue. > > I would agree that there is no reason to change what you > have for generic queueing. But for taskqueue_swi currently > and a possibly others in the future you not only need to > queue the event you want to cause a software interrupt to occur > at the soonest reasonable time. Putting the item on the work > queue does not seem sufficient. In particular I would argue the > following should be avoided [ ... ] I partly agree with Chuck, particularly on avoiding this. But his suggestion bears a striking resemblence to priority bands in the SVR4.x streams implementations. I'd argue that this would be a mistake; in particular, it means that there is a signle band-based contention domain for insertion, deletion, and queue contents iteration, which itself is not SMP scalable. In my experience with the UnixWare 2.x (SVR4.2) kernel, the limits on scaling derive from contention. I believe that the SVR4.x/Solaris(pre 2.5) models are inherently flawed in terms of scaling, in the same way that the Solaris SLAB allocator in 2.x was inherently flawed for SMP scaling. When I say "SMP scaling", please also read "Real Time" and "kernel preemption", since they are spatially similar problems. I could see where you could abuse Chuck's "banding" suggestion in order to establish per CPU "bands" (worst case: allocate the name space for flags above bit 3 (2^32), and OR in an option based 0 CPU ID). This is, I think, a folley to be avoided. 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