From: Kent Overstreet <kent.overstreet@gmail.com>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-xfs@vger.kernel.org, axboe@fb.com,
linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org
Subject: Re: [PATCH 5/6] iomap: implement direct I/O
Date: Tue, 25 Oct 2016 07:31:56 -0800 [thread overview]
Message-ID: <20161025153156.cjhcvvoxd3c6pqf7@kmo-pixel> (raw)
In-Reply-To: <1477408098-10153-6-git-send-email-hch@lst.de>
On Tue, Oct 25, 2016 at 05:08:17PM +0200, Christoph Hellwig wrote:
> This adds a full fledget direct I/O implementation using the iomap
> interface. Full fledged in this case means all features are supported:
> AIO, vectored I/O, any iov_iter type including kernel pointers, bvecs
> and pipes, support for hole filling and async apending writes. It does
> not mean supporting all the warts of the old generic code. We expect
> i_rwsem to be held over the duration of the call, and we expect to
> maintain i_dio_count ourselves, and we pass on any kinds of mapping
> to the file system for now.
>
> The algorithm used is very simple: We use iomap_apply to iterate over
> the range of the I/O, and then we use the new bio_iov_iter_get_pages
> helper to lock down the user range for the size of the extent.
> bio_iov_iter_get_pages can currently lock down twice as many pages as
> the old direct I/O code did, which means that we will have a better
> batch factor for everything but overwrites of badly fragmented files.
It's definitely simpler :)
So you're still walking the mappings, then for each mapping allocating a bio and
pinning pages - opposite of my approach, I started out by allocating a bio and
pinning pages and then walk the mapping, splitting the bio as needed.
I still like my approach better, I think it ought to perform better when doing
fragmented IOs and it feels cleaner to me - you're not going back and forth
between calling into the gup() code, and your filesystem's btree code, both of
which are going to require taking their own set of locks and such. That said, I
doubt it's much of a difference and your code is so much simpler than
direct-IO.c that who cares :)
Do you have your code up in a git repo somewhere? I'm going to compare it to
bcachefs's dio code and see if I can remember all edge cases I hit when I was
working on that.
bcachefs's dio code, for reference:
https://evilpiepirate.org/git/linux-bcache.git/tree/drivers/md/bcache/fs-io.c?h=bcache-dev#n1268
next prev parent reply other threads:[~2016-10-25 15:32 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-25 15:08 Christoph Hellwig
2016-10-25 15:08 ` [PATCH 1/6] locking/lockdep: Provide a type check for lock_is_held Christoph Hellwig
2016-10-25 15:08 ` [PATCH 2/6] xfs: remove i_iolock and use i_rwsem in the VFS inode instead Christoph Hellwig
2016-10-25 15:08 ` [PATCH 3/6] block: add bio_iov_iter_get_pages() Christoph Hellwig
2016-10-25 15:08 ` [PATCH 4/6] fs: make sb_init_dio_done_wq available outside of direct-io.c Christoph Hellwig
2016-10-25 15:08 ` [PATCH 5/6] iomap: implement direct I/O Christoph Hellwig
2016-10-25 15:31 ` Kent Overstreet [this message]
2016-10-25 16:34 ` Christoph Hellwig
2016-10-25 17:13 ` Kent Overstreet
2016-10-26 7:44 ` Christoph Hellwig
2016-10-25 19:51 ` Kent Overstreet
2016-10-26 7:57 ` Christoph Hellwig
2016-10-26 13:53 ` Bob Peterson
2016-10-26 14:02 ` Christoph Hellwig
2016-10-25 15:08 ` [PATCH 6/6] xfs: use iomap_dio_rw Christoph Hellwig
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=20161025153156.cjhcvvoxd3c6pqf7@kmo-pixel \
--to=kent.overstreet@gmail.com \
--cc=axboe@fb.com \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@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.