[illumos-Developer] initial review: bombproof taskq dispatch
Garrett D'Amore
garrett at nexenta.com
Wed Jul 6 17:06:25 PDT 2011
On Wed, 2011-07-06 at 19:30 -0400, Albert Lee wrote:
> On Thu, Jun 30, 2011 at 1:36 PM, Albert Lee <trisk at opensolaris.org> 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.
> >
> > -Albert
> >
>
> Gordon pointed out in the Nexenta review that flags = TQ_SLEEP should
> still remain for zio so as not to change the #ifndef _KERNEL
> behaviour. Sorry to derail your RTI.
TQ_SLEEP vs. DDI_NOSLEEP have no difference for userland. They both
just call malloc(). Anyway, those changes were not in this code, but in
your changes to iscsit, which is not part of this cset.
- Garrett
>
> -Albert
>
> _______________________________________________
> Developer mailing list
> Developer at lists.illumos.org
> http://lists.illumos.org/m/listinfo/developer
More information about the Developer
mailing list