From: Mike Snitzer <snitzer@redhat.com>
To: Bart Van Assche <bart.vanassche@sandisk.com>
Cc: axboe@kernel.dk, device-mapper development <dm-devel@redhat.com>,
hch@lst.de, linux-block@vger.kernel.org
Subject: should blk-mq halt requeue processing while queue is frozen? [was: Re: [PATCH 8/9] dm: Fix two race conditions related to stopping and starting queues]
Date: Fri, 2 Sep 2016 12:10:59 -0400 [thread overview]
Message-ID: <20160902161059.GB17508@redhat.com> (raw)
In-Reply-To: <20160902151213.GA17508@redhat.com>
On Fri, Sep 02 2016 at 11:12am -0400,
Mike Snitzer <snitzer@redhat.com> wrote:
> So in the case of blk-mq request-based DM: we cannot expect
> blk_mq_freeze_queue(), during suspend, to complete if requests are
> getting requeued to the blk-mq queue via BLK_MQ_RQ_QUEUE_BUSY.
Looking closer at blk-mq. Currently __blk_mq_run_hw_queue() will move
any requeued requests to the hctx->dispatch list and then performs async
blk_mq_run_hw_queue().
To do what you hoped (have blk_mq_freeze_queue() discontinue all use of
blk-mq hw queues during DM suspend) I think we'd need blk-mq to:
1) avoid processing requeued IO if blk_mq_freeze_queue() was used to
freeze the queue. Meaning it'd have to hold requeued work longer
than it currently does.
2) Then once blk_mq_unfreeze_queue() is called it'd allow requeues to
proceed.
This would be catering to a very specific requirement of DM (given it
re-queues IO back to the request_queue during suspend).
BUT all said, relative to request-based DM multipath, what we have is
perfectly fine on a correctness level: the requests are re-queued
because the blk-mq DM device is suspended.
Unfortunately on an efficiency level DM suspend creates a lot of busy
looping in blk-mq, with 100% cpu usage in a threads with names
"kworker/3:1H", ideally we'd avoid that!
next prev parent reply other threads:[~2016-09-02 16:10 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-31 22:14 [PATCH 0/9] dm patches for kernel v4.9 Bart Van Assche
2016-08-31 22:15 ` [PATCH 1/9] blk-mq: Introduce blk_mq_queue_stopped() Bart Van Assche
2016-08-31 22:16 ` [PATCH 2/9] dm: Rename a function argument Bart Van Assche
2016-09-01 3:29 ` Mike Snitzer
2016-09-01 14:17 ` Bart Van Assche
2016-08-31 22:16 ` [PATCH 3/9] dm: Introduce signal_pending_state() Bart Van Assche
2016-08-31 22:16 ` [PATCH 4/9] dm: Convert wait loops Bart Van Assche
2016-08-31 22:17 ` [PATCH 5/9] dm: Add two lockdep_assert_held() statements Bart Van Assche
2016-08-31 22:17 ` [PATCH 6/9] dm: Simplify dm_old_stop_queue() Bart Van Assche
2016-08-31 22:17 ` [PATCH 7/9] dm: Mark block layer queue dead before destroying the dm device Bart Van Assche
2016-08-31 22:18 ` [PATCH 8/9] dm: Fix two race conditions related to stopping and starting queues Bart Van Assche
2016-09-01 3:13 ` Mike Snitzer
2016-09-01 14:23 ` Bart Van Assche
2016-09-01 15:05 ` Mike Snitzer
2016-09-01 15:31 ` Bart Van Assche
2016-09-01 15:50 ` Mike Snitzer
2016-09-01 16:12 ` Mike Snitzer
2016-09-01 17:59 ` Bart Van Assche
2016-09-01 19:05 ` Mike Snitzer
2016-09-01 19:35 ` Mike Snitzer
2016-09-01 20:15 ` Bart Van Assche
2016-09-01 20:33 ` Mike Snitzer
2016-09-01 20:39 ` Bart Van Assche
2016-09-01 20:48 ` Mike Snitzer
2016-09-01 20:52 ` Bart Van Assche
2016-09-01 21:17 ` Mike Snitzer
2016-09-01 22:18 ` Mike Snitzer
2016-09-01 22:22 ` Bart Van Assche
2016-09-01 22:26 ` Mike Snitzer
2016-09-01 23:17 ` Bart Van Assche
2016-09-01 23:47 ` Mike Snitzer
2016-09-02 0:03 ` Bart Van Assche
2016-09-02 15:12 ` Mike Snitzer
2016-09-02 16:10 ` Mike Snitzer [this message]
2016-09-02 22:42 ` [dm-devel] should blk-mq halt requeue processing while queue is frozen? Bart Van Assche
2016-09-02 22:42 ` Bart Van Assche
2016-09-03 0:34 ` Mike Snitzer
2016-09-07 16:41 ` Mike Snitzer
2016-09-13 8:01 ` [dm-devel] " Bart Van Assche
2016-09-13 14:36 ` Mike Snitzer
2016-08-31 22:18 ` [PATCH 9/9] dm path selector: Avoid that device removal triggers an infinite loop Bart Van Assche
2016-09-01 2:49 ` Mike Snitzer
2016-09-01 14:14 ` Bart Van Assche
2016-09-01 15:06 ` Mike Snitzer
2016-09-01 15:22 ` Bart Van Assche
2016-09-01 15:26 ` Mike Snitzer
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=20160902161059.GB17508@redhat.com \
--to=snitzer@redhat.com \
--cc=axboe@kernel.dk \
--cc=bart.vanassche@sandisk.com \
--cc=dm-devel@redhat.com \
--cc=hch@lst.de \
--cc=linux-block@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.