mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: block device direct I/O fast path
Date: Tue, 1 Nov 2016 11:00:19 -0600	[thread overview]
Message-ID: <20161101170019.GB9797@kernel.dk> (raw)
In-Reply-To: <1477936765-8828-1-git-send-email-hch@lst.de>

On Mon, Oct 31 2016, Christoph Hellwig wrote:
> Hi Jens,
> 
> this small series adds a fasth path to the block device direct I/O
> code.  It uses new magic created by Kent to avoid allocating an array
> for the pages, and as part of that allows small, non-aio direct I/O
> requests to be done without memory allocations or atomic ops and with
> a minimal cache footprint.  It's basically a cut down version of the
> new iomap direct I/O code, and in the future it might also make sense
> to move the main direct I/O code to a similar model.  But indepedent
> of that it's always worth to optimize the case of small, non-I/O
> requests as allocating the bio and biovec on stack and a trivial
> completion handler will always win over a full blown implementation.

I'm not particularly tied to the request based implementation that I did
here:

http://git.kernel.dk/cgit/linux-block/log/?h=blk-dio

I basically wanted to solve two problems with that:

1) The slow old direct-io.c code
2) Implement the hybrid polling

#1 is accomplished with your code as well, though it does lack suppor
for async IO, but that would not be hard to add.

#2 is a bit more problematic, I'm pondering how we can implement that on
top of the bio approach. The nice thing about the request based approach
is that we have a 1:1 mapping with the unit on the driver side. And we
have a place to store the timer. I don't particularly love the embedded
timer, however, it'd be great to implement that differently. Trying to
think of options there, haven't found any yet.

-- 
Jens Axboe

  parent reply	other threads:[~2016-11-01 17:01 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-31 17:59 Christoph Hellwig
2016-10-31 17:59 ` [PATCH 1/2] block: add bio_iov_iter_get_pages() Christoph Hellwig
2016-11-01  1:05   ` Ming Lei
2016-11-01 14:19     ` Christoph Hellwig
2016-10-31 17:59 ` [PATCH 2/2] block: fast-path for small and simple direct I/O requests Christoph Hellwig
2016-10-31 23:19   ` Omar Sandoval
2016-11-01 14:18     ` Christoph Hellwig
2016-11-01 17:00 ` Jens Axboe [this message]
2016-11-01 17:06   ` block device direct I/O fast path Christoph Hellwig
2016-11-01 17:54     ` Jens Axboe
2016-11-01 18:22       ` Jens Axboe

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=20161101170019.GB9797@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=hch@lst.de \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome