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

From: Stefan Richter
Date: Wed May 22 2013 - 08:58:31 EST


On May 22 Stephan Gatzka wrote:
[I wrote:]
> > A third (fourth?) way to fix it --- feasible or not --- would be to break
> > the dependency between the worklets. In this case, use a timer to cancel
> > outbound transactions if the request-transmit IRQ event was not received
> > before a timeout. We had such a timeout in the older ieee1394 drivers and
> > we also had it in earlier versions of the firewire drivers, at a risk of a
> > race between CPU and OHCI.
>
> Why do we need a timer? If we guarantee that bus_reset_work() always
> make progress (if we put it into its own queue), it should always be
> able to complete the corresponding completion object the other works are
> waiting for.

We don't need a timer if the dual-wq solution is implemented. It's just
that there are four different solutions possible in principle. Any one
of these fixes is sufficient on its own:

Problem --- A WQ_MEM_RECLAIM workqueue will, for some periods of time,
offer a concurrency level of only 1; particularly during memory reclaim,
but also in some other situations due to the way how it is implemented (as
far as I understood yesterday's posts). Therefore, interdependent works
must not be inserted into the same WQ_MEM_RECLAIM workqueue instance.

Solution 1 --- Don't set the WQ_MEM_RECLAIM flag. This is only possible
if memory reclaim does not depend on any one of the works that are
inserted into this queue. (This solution is therefore not available to
an SBP-2 initiator.)

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

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.

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).
--
Stefan Richter
-=====-===-= -=-= =-==-
http://arcgraph.de/sr/
--
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/