public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: stephan.gatzka@gmail.com
Cc: Tejun Heo <tj@kernel.org>,
	Peter Hurley <peter@hurleysoftware.com>,
	linux1394-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: Re: function call fw_iso_resource_mange(..) (core-iso.c) does not return
Date: Wed, 22 May 2013 14:58:08 +0200	[thread overview]
Message-ID: <20130522145808.1ec7bea7@stein> (raw)
In-Reply-To: <51145028d1c880d68e0a88d863faa71c@gatzka.org>

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/

  reply	other threads:[~2013-05-22 12:58 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <8ac7ca3200325ddf85ba57aa6d000f70@gatzka.org>
2013-05-21 20:28 ` function call fw_iso_resource_mange(..) (core-iso.c) does not return Stefan Richter
2013-05-22  9:08   ` Stephan Gatzka
2013-05-22  9:22     ` Tejun Heo
2013-05-22 13:11     ` Stefan Richter
     [not found] ` <519BA6AC.1080600@hurleysoftware.com>
2013-05-21 21:13   ` Stefan Richter
2013-05-22  8:53     ` Stephan Gatzka
2013-05-22 13:38     ` Peter Hurley
     [not found]   ` <62922216e6007f9ef83956e0ca202644@gatzka.org>
2013-05-21 21:53     ` Stefan Richter
2013-05-21 22:10       ` Peter Hurley
2013-05-22  8:52         ` Stephan Gatzka
     [not found]   ` <20130521231847.GA6985@mtj.dyndns.org>
2013-05-22  7:48     ` Stefan Richter
2013-05-22  8:59       ` Stephan Gatzka
2013-05-22 12:58         ` Stefan Richter [this message]
2013-05-22 13:06           ` Stephan Gatzka
2013-05-22 13:21             ` Peter Hurley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130522145808.1ec7bea7@stein \
    --to=stefanr@s5r6.in-berlin.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux1394-devel@lists.sourceforge.net \
    --cc=peter@hurleysoftware.com \
    --cc=stephan.gatzka@gmail.com \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox