Date: Wed, 17 May 2000 17:35:02 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: cp@bsdi.com (Chuck Paterson) Cc: dfr@nlsystems.com (Doug Rabson), arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution Message-ID: <200005171735.KAA06172@usr05.primenet.com> In-Reply-To: <200005132342.RAA01739@berserker.bsdi.com> from "Chuck Paterson" at May 13, 2000 05:42:23 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> }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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200005171735.KAA06172>