linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Asias He <asias@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>, linux-fsdevel@vger.kernel.org
Subject: Re: [RFC PATCH 2/5] block: Do not stop draining if waitqueue is not empty.
Date: Wed, 23 May 2012 22:54:11 +0800	[thread overview]
Message-ID: <4FBCFA13.5030401@redhat.com> (raw)
In-Reply-To: <20120522150742.GA14339@google.com>

On 05/22/2012 11:07 PM, Tejun Heo wrote:
> Hello, Asias.
>
> On Tue, May 22, 2012 at 02:48:55PM +0800, Asias He wrote:
>> I actually saw this happened though it should not happen. I have no
>> idea why this happens. Maybe unbalanced prepare_to_wait_exclusive()
>> in get_request_wait() and wake_up() in __freed_request()?
>
> Hmm.... unbalanced how?  I think bugs in this area are much more
> likely to show up as live queue hang rather than issues during queue
> shutdown.

I added some debug code to count the number of sleep and wakeup in 
get_request_wait() and __freed_request().

I found this after queue cleanup. rl->wait[] is not empty while 
rl->count[] == 0. There are exactly nr_sleep - nr_wakeup of process in D 
state. So missed wakeup happens? Any ideas to do more debug to find the 
root-cause?

[   52.917115] ---> nr_sleep=1046, nr_wakeup=873, delta=173

$ vmstat 1
  1 173  0 712640  24292  96172 0 0  0  0  419  757  0  0  0 100  0
  0 173  0 712764  24292  96180 0 0  0  0  472  725  0  1  0 97  2


>> With this happened, I saw some fio threads in D state which are
>> sleeping on get_request_wait(). If I wake up the threads in the wait
>> queue in q->abort_queue_fn() callback which i proposed in the 1/5 of
>> this patch set, the queue cleanup and thus hot-unplug went pretty
>> well. (Passed 3000~ rounds of test, without this 2~ round of test
>> would fail). See this patch [RFC PATCH 4/5] virtio-blk: Use
>> q->abort_queue_fn() to abort.
>
> If the problem is that easily reproducible (you mean that you can
> reproduce it every other time, right?), it would be immensely helpful
> if you can root cause the issue properly.  As it currently stands,
> this series seems to work around the problem by adding extra API
> without properly root-causing it.  Workarounds without proper
> root-causing are already pretty bad and adding extra API for that is
> rather silly, IMHO.

Yes. it is very easy to reproduce. /me Trying to figure the root cause out.

-- 
Asias

  reply	other threads:[~2012-05-23 14:53 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-21  9:08 [RFC PATCH 1/5] block: Introduce q->abort_queue_fn() Asias He
2012-05-21  9:08 ` [RFC PATCH 2/5] block: Do not stop draining if waitqueue is not empty Asias He
2012-05-21 15:39   ` Tejun Heo
2012-05-22  6:48     ` Asias He
2012-05-22 15:07       ` Tejun Heo
2012-05-23 14:54         ` Asias He [this message]
2012-05-25  1:16           ` Asias He
2012-05-28  0:30             ` Tejun Heo
2012-05-28  3:39               ` Asias He
2012-05-21  9:08 ` [RFC PATCH 4/5] virtio-blk: Use q->abort_queue_fn() to abort requests Asias He
2012-05-21 15:42 ` [RFC PATCH 1/5] block: Introduce q->abort_queue_fn() Tejun Heo
2012-05-22  7:30   ` Asias He
2012-05-22 15:14     ` Tejun Heo
2012-05-23 15:04       ` Asias He

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=4FBCFA13.5030401@redhat.com \
    --to=asias@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=linux-fsdevel@vger.kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).