From: Christoph Hellwig <hch@infradead.org>
To: Arianna Avanzini <avanzini.arianna@gmail.com>
Cc: konrad.wilk@oracle.com, boris.ostrovsky@oracle.com,
david.vrabel@citrix.com, xen-devel@lists.xenproject.org,
linux-kernel@vger.kernel.org, hch@infradead.org,
bob.liu@oracle.com, felipe.franciosi@citrix.com, axboe@fb.com
Subject: Re: [PATCH RFC v2 1/5] xen, blkfront: port to the the multi-queue block layer API
Date: Sat, 13 Sep 2014 12:29:58 -0700 [thread overview]
Message-ID: <20140913192958.GA31744@infradead.org> (raw)
In-Reply-To: <1410479844-2864-2-git-send-email-avanzini.arianna@gmail.com>
> +static int blkfront_queue_rq(struct blk_mq_hw_ctx *hctx, struct request *req)
> {
> + struct blkfront_info *info = req->rq_disk->private_data;
>
> + spin_lock_irq(&info->io_lock);
> + if (RING_FULL(&info->ring))
> + goto wait;
>
> - blk_start_request(req);
> + if ((req->cmd_type != REQ_TYPE_FS) ||
> + ((req->cmd_flags & (REQ_FLUSH | REQ_FUA)) &&
> + !info->flush_op)) {
> + req->errors = -EIO;
> + blk_mq_complete_request(req);
> + spin_unlock_irq(&info->io_lock);
> + return BLK_MQ_RQ_QUEUE_ERROR;
As mentioned during the last round this should only return
BLK_MQ_RQ_QUEUE_ERROR, and not also set req->errors and complete the
request.
> + }
>
> + if (blkif_queue_request(req)) {
> + blk_mq_requeue_request(req);
> + goto wait;
Same here, this should only return BLK_MQ_RQ_QUEUE_BUSY after the wait
label, but not also requeue the request. While the error case above
is harmless due to the double completion protection in blk-mq, this one
actually is actively harmful.
> wait:
> + /* Avoid pointless unplugs. */
> + blk_mq_stop_hw_queue(hctx);
> + spin_unlock_irq(&info->io_lock);
In general you should try to do calls into the blk_mq code without holding
your locks to simplify the locking hierachy and reduce lock hold times.
> -static void kick_pending_request_queues(struct blkfront_info *info)
> +static void kick_pending_request_queues(struct blkfront_info *info,
> + unsigned long *flags)
> {
> if (!RING_FULL(&info->ring)) {
> - /* Re-enable calldowns. */
> - blk_start_queue(info->rq);
> - /* Kick things off immediately. */
> - do_blkif_request(info->rq);
> + spin_unlock_irqrestore(&info->io_lock, *flags);
> + blk_mq_start_stopped_hw_queues(info->rq, 0);
> + spin_lock_irqsave(&info->io_lock, *flags);
> }
The second paramter to blk_mq_start_stopped_hw_queues is a bool,
so you should pass false instead of 0 here.
Also the locking in this area seems wrong as most callers immediately
acquire and/or release the io_lock, so it seems more useful in general
to expect this function to be called without it.
> static void blkif_restart_queue(struct work_struct *work)
> {
> struct blkfront_info *info = container_of(work, struct blkfront_info, work);
> + unsigned long flags;
>
> - spin_lock_irq(&info->io_lock);
> + spin_lock_irqsave(&info->io_lock, flags);
There shouldn't be any need to ever take a lock as _irqsave from a work
queue handler.
Note that you might be able to get rid of your own workqueue here by
simply using blk_mq_start_stopped_hw_queues with the async paramter set
to true.
>
> - error = (bret->status == BLKIF_RSP_OKAY) ? 0 : -EIO;
> + error = req->errors = (bret->status == BLKIF_RSP_OKAY) ? 0 : -EIO;
I don't think you need the error variable any more as blk-mq always uses
req->errors to pass the errno value.
> - kick_pending_request_queues(info);
> + kick_pending_request_queues(info, &flags);
>
> list_for_each_entry_safe(req, n, &requests, queuelist) {
> /* Requeue pending requests (flush or discard) */
> list_del_init(&req->queuelist);
> BUG_ON(req->nr_phys_segments > segs);
> - blk_requeue_request(info->rq, req);
> + blk_mq_requeue_request(req);
Note that blk_mq_requeue_request calls will need a
blk_mq_kick_requeue_list call to be actually requeued. It should be
fine to have one past this loop here.
next prev parent reply other threads:[~2014-09-13 19:30 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-11 23:57 [PATCH RFC v2 0/5] Multi-queue support for xen-blkfront and xen-blkback Arianna Avanzini
2014-09-11 23:57 ` [PATCH RFC v2 1/5] xen, blkfront: port to the the multi-queue block layer API Arianna Avanzini
2014-09-13 19:29 ` Christoph Hellwig [this message]
2014-10-01 20:18 ` Konrad Rzeszutek Wilk
2014-09-11 23:57 ` [PATCH RFC v2 2/5] xen, blkfront: introduce support for multiple block rings Arianna Avanzini
2014-10-01 20:18 ` Konrad Rzeszutek Wilk
2014-09-11 23:57 ` [PATCH RFC v2 3/5] xen, blkfront: negotiate the number of block rings with the backend Arianna Avanzini
2014-09-12 10:46 ` David Vrabel
2014-10-01 20:18 ` Konrad Rzeszutek Wilk
2014-09-11 23:57 ` [PATCH RFC v2 4/5] xen, blkback: introduce support for multiple block rings Arianna Avanzini
2014-10-01 20:18 ` Konrad Rzeszutek Wilk
2014-09-11 23:57 ` [PATCH RFC v2 5/5] xen, blkback: negotiate of the number of block rings with the frontend Arianna Avanzini
2014-09-12 10:58 ` David Vrabel
2014-10-01 20:23 ` Konrad Rzeszutek Wilk
2014-10-01 20:27 ` [PATCH RFC v2 0/5] Multi-queue support for xen-blkfront and xen-blkback Konrad Rzeszutek Wilk
2015-04-28 7:36 ` Christoph Hellwig
2015-04-28 7:46 ` Arianna Avanzini
2015-05-13 10:29 ` Bob Liu
2015-06-30 14:21 ` [Xen-devel] " Marcus Granado
2015-07-01 0:04 ` Bob Liu
2015-07-01 3:02 ` Jens Axboe
2015-08-10 11:03 ` Rafal Mielniczuk
2015-08-10 11:14 ` Bob Liu
2015-08-10 15:52 ` Jens Axboe
2015-08-11 6:07 ` Bob Liu
2015-08-11 9:45 ` Rafal Mielniczuk
2015-08-11 17:32 ` Jens Axboe
2015-08-12 10:16 ` Bob Liu
2015-08-12 16:46 ` Rafal Mielniczuk
2015-08-14 8:29 ` Bob Liu
2015-08-14 12:30 ` Rafal Mielniczuk
2015-08-18 9:45 ` Rafal Mielniczuk
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=20140913192958.GA31744@infradead.org \
--to=hch@infradead.org \
--cc=avanzini.arianna@gmail.com \
--cc=axboe@fb.com \
--cc=bob.liu@oracle.com \
--cc=boris.ostrovsky@oracle.com \
--cc=david.vrabel@citrix.com \
--cc=felipe.franciosi@citrix.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=xen-devel@lists.xenproject.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).