linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Kent Overstreet <kent.overstreet@gmail.com>
Cc: Christoph Hellwig <hch@lst.de>,
	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 18:34:43 +0200	[thread overview]
Message-ID: <20161025163443.GA8730@lst.de> (raw)
In-Reply-To: <20161025153156.cjhcvvoxd3c6pqf7@kmo-pixel>

On Tue, Oct 25, 2016 at 07:31:56AM -0800, Kent Overstreet wrote:
> 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 :)

Yes, this is the basic idea behind the whole iomap code - we have
a generic apply function that calls into the fs allocator, and then
takes a callback that it applies to one extent at a time.  It really
helps a lot to separate responsibilities and factor the code into
independent functions.

I looked at carrying over bios between different invocations of the
callback, but it quickly turned into a mess.  In the end the only thing
we'd optimize with it is the gup call - bios would have to be split
anyway, etc, etc.  So with this code there indeed is a worsr case
for badly fragmented files, but I'd rather work on the fs allocator
to further reduce the amount of fragmentation we have rather than
working around it.  E.g. for XFS Darrick and I have sketched a rough
plan for an auto-COW mode where we'd simply not reuse fragmented blocks
for an overwrite and will instead give the caller a nice contiguous
single extent.

> 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.

Git:

git://git.infradead.org/users/hch/vfs.git iomap-dio

Gitweb:

http://git.infradead.org/users/hch/vfs.git/shortlog/refs/heads/iomap-dio

  reply	other threads:[~2016-10-25 16:34 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
2016-10-25 16:34     ` Christoph Hellwig [this message]
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=20161025163443.GA8730@lst.de \
    --to=hch@lst.de \
    --cc=axboe@fb.com \
    --cc=kent.overstreet@gmail.com \
    --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 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).