All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Richard Weinberger <richard@nod.at>
Cc: user-mode-linux-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org, axboe@fb.com,
	anton.ivanov@cambridgegreys.com, hch@lst.de,
	linux-block@vger.kernel.org
Subject: Re: [PATCH] [RFC] um: Convert ubd driver to blk-mq
Date: Wed, 29 Nov 2017 22:46:51 +0100	[thread overview]
Message-ID: <20171129214651.GA5846@lst.de> (raw)
In-Reply-To: <20171126131053.32300-1-richard@nod.at>

On Sun, Nov 26, 2017 at 02:10:53PM +0100, Richard Weinberger wrote:
> MAX_SG is 64, used for blk_queue_max_segments(). This comes from
> a0044bdf60c2 ("uml: batch I/O requests"). Is this still a good/sane
> value for blk-mq?

blk-mq itself doesn't change the tradeoff.

> The driver does IO batching, for each request it issues many UML struct
> io_thread_req request to the IO thread on the host side.
> One io_thread_req per SG page.
> Before the conversion the driver used blk_end_request() to indicate that
> a part of the request is done.
> blk_mq_end_request() does not take a length parameter, therefore we can
> only mark the whole request as done. See the new is_last property on the
> driver.
> Maybe there is a way to partially end requests too in blk-mq?

You can, take a look at scsi_end_request which handles this for blk-mq
and the legacy layer.  That being said I wonder if batching really
makes that much sene if you execute each segment separately?

> Another obstacle with IO batching is that UML IO thread requests can
> fail. Not only due to OOM, also because the pipe between the UML kernel
> process and the host IO thread can return EAGAIN.
> In this case the driver puts the request into a list and retried later
> again when the pipe turns writable.
> I’m not sure whether this restart logic makes sense with blk-mq, maybe
> there is a way in blk-mq to put back a (partial) request?

blk_mq_requeue_request requeues requests that have been partially
exectuted (or not at all for that matter).


  parent reply	other threads:[~2017-11-29 21:46 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-26 13:10 [uml-devel] [PATCH] [RFC] um: Convert ubd driver to blk-mq Richard Weinberger
2017-11-26 13:10 ` Richard Weinberger
2017-11-26 13:41 ` [uml-devel] " Anton Ivanov
2017-11-26 13:56   ` Richard Weinberger
2017-11-26 14:42     ` Anton Ivanov
2017-11-26 14:42       ` Anton Ivanov
2017-11-29 21:46 ` Christoph Hellwig [this message]
2017-12-03 21:54   ` Richard Weinberger
2017-12-03 22:23     ` Anton Ivanov

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=20171129214651.GA5846@lst.de \
    --to=hch@lst.de \
    --cc=anton.ivanov@cambridgegreys.com \
    --cc=axboe@fb.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=richard@nod.at \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    /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.