[illumos-Developer] initial review: bombproof taskq dispatch

[Garrett D'Amore]

On Thu, 2011-06-30 at 13:36 -0400, Albert Lee wrote:
> On Wed, May 4, 2011 at 8:11 PM, Garrett D'Amore <garrett at nexenta.com> wrote:
> > On Wed, 2011-05-04 at 18:52 -0500, Jason King wrote:
> >
> >>
> >>
> >>
> >> With the preface that a number of these questions are also partially
> >> for my own edification, so these might be more than a bit ignorant :)
> >>
> >>
> >> This change would seem to ignore any limits on the number of threads
> >> for a taskq (or rather it appears you could create more static
> >> taskq_ent_t's than the limit for the taskq & dispatch all of them).
> >> A lot of the logic within taskq_dispatch seems to depend on this limit
> >> (and in fact the taskq itself allocates max_nthreads # of kthread_t
> >> structures).  Is this correct?
> >
> > Nothing I've done touches the threading stuff... the only thing is that
> > my stuff is totally incompatible with dynamic taskqs.  Folks using
> > dynamic taskqs don't want this prealloc behavior anyway, because dynamic
> > taskq dispatch might actually create whole threads. :-)
> >
> 
> We have an effectively unlimited queue length here, given that we
> ignore taskq_{min,max}alloc. Those values are specified at
> taskq_create separately from the thread count, though.

This is true.  This interface will allow the queue to grow without
bound.  I don't see that as a problem since we're not allocating any
resources (apart from the future allocation of CPU time to process the
task. :-)

In fact, if you look at the way many of these were called, the maxalloc
was never used to limit task entries, but allocations.  In the case of
non-sleeping allocations it would fail, but a sleeping allocation would
just block the caller until there was room.  These bits were about
tuning the cache.  With a preallocated entry, its totally irrelevant, as
there isn't really a "cache" of these things.

	- Garrett