From mboxrd@z Thu Jan 1 00:00:00 1970 From: Asias He Subject: Re: [RFC PATCH 2/5] block: Do not stop draining if waitqueue is not empty. Date: Tue, 22 May 2012 14:48:55 +0800 Message-ID: <4FBB36D7.9030202@redhat.com> References: <1337591313-26333-1-git-send-email-asias@redhat.com> <1337591313-26333-2-git-send-email-asias@redhat.com> <20120521153922.GA6549@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Jens Axboe , linux-fsdevel@vger.kernel.org To: Tejun Heo Return-path: Received: from mx1.redhat.com ([209.132.183.28]:19371 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750896Ab2EVGsD (ORCPT ); Tue, 22 May 2012 02:48:03 -0400 In-Reply-To: <20120521153922.GA6549@google.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 05/21/2012 11:39 PM, Tejun Heo wrote: > On Mon, May 21, 2012 at 05:08:30PM +0800, Asias He wrote: >> If there are processes still in the wait queue, keep draining, >> otherwise these processes would be in D state forever. >> >> I noticed this situation: >> q->rq.count[0] == 0, q->rq.count[1] == 0, however wait queue >> q->rq.wait[0].task_list and q->rq.wait[1].task_list are not empty. >> >> Cc: Jens Axboe >> Cc: Tejun Heo >> Cc: linux-fsdevel@vger.kernel.org >> Signed-off-by: Asias He >> --- >> block/blk-core.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/block/blk-core.c b/block/blk-core.c >> index ca42fd7..2c2b585 100644 >> --- a/block/blk-core.c >> +++ b/block/blk-core.c >> @@ -394,6 +394,7 @@ void blk_drain_queue(struct request_queue *q, bool drain_all) >> drain |= q->rq.count[i]; >> drain |= q->in_flight[i]; >> drain |= !list_empty(&q->flush_queue[i]); >> + drain |= waitqueue_active(&q->rq.wait[i]); > > Hmm... how does that happen? What do you mean "you noticed this > situation"? Did that actually happen or you noticed such scenarios > would be possible? If rl.wait[] isn't empty with zero rq count, the > queue would hang, so we should be fixing that situation instead of > working around it from cleanup_queue. Hi, Tejun 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()? 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. -- Asias