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

From: Peter Hurley
Date: Wed May 22 2013 - 09:22:11 EST

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.]

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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at