Re: function call fw_iso_resource_mange(..) (core-iso.c) does notreturn

[Peter Hurley]

On 05/22/2013 09:06 AM, Stephan Gatzka wrote:
> > Solution 2 --- Perform interdependent works in different queue instances.
> > (Keep the WQ_MEM_RECLAIM flag set at those workqueues that have to take
> > work which is necessary for progress of memory reclaim.  If this and only
> > this solution is employed for an SBP-2 initiator, we need two if not more
> > WQ_MEM_RECLAIM workqueue instances.)
>
> I would go for this solution. I have no problems with lots of workqueues around, because there is only a relatively small structure required for each workqueue.

Now that we more fully understand the cause, this would be my choice as
well (despite my earlier advocacy for the return to tasklets).

Although we do need to carefully review the other work items (bm_work,br_work)
to ensure that there aren't unwanted dependencies with those as well.

Also, wqs that are WQ_MEM_RECLAIM aren't free as each wq will have a
dedicated rescue thread.

[The other advantage with tasklets is the reduced latency but I do
understand the advantages of the RT characteristics of worklets.]

Regards,
Peter Hurley

> > Solution 3 --- Remove the dependency between worklets:
> >
> >     Solution 3a --- Remove the lower-level worklet altogether.
> >     E.g. reimplement the lower-level worklet as a tasklet.
>
> No, I like the workqueue context. :)
>
>
> >     Solution 3b --- Remove the higher-level worklet's dependency.
> >     E.g. reimplement the higher-level worklet such that it is woken by
> >     a timer and then aborts or reschedules ( = lets the lower-level
> >     worklet bubble up in the queue).
>
> This looks more difficult to me and not so easy to test.
>
> Stephan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/