Skip site navigation (1)Skip section navigation (2)
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>