All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Kent Overstreet <kmo@daterainc.com>
Cc: Jens Axboe <axboe@kernel.dk>,
	Christoph Hellwig <hch@infradead.org>,
	Sage Weil <sage@inktank.com>, Zach Brown <zab@redhat.com>,
	Mark Fasheh <mfasheh@suse.com>,
	xfs@oss.sgi.com, Steve French <sfrench@samba.org>,
	Dave Kleikamp <dave.kleikamp@oracle.com>,
	Joel Becker <jlbec@evilplan.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Anton Altaparmakov <anton@tuxera.com>
Subject: Re: [RFC] unifying write variants for filesystems
Date: Tue, 4 Feb 2014 18:08:37 +0000	[thread overview]
Message-ID: <20140204180837.GJ10323@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CALJ65z=HhYnc1eD-Kpk0s=Eod6sHJq1jnJirUNc7-9s1rFV1HQ@mail.gmail.com>

On Tue, Feb 04, 2014 at 09:35:06AM -0800, Kent Overstreet wrote:
> > I think Kent is talking about what happens after the user addresses are
> > consumed.  Turning dio into more of a bio mapping and redirection engine
> > would use more of the bio machinery instead of the bits that dio has
> > implemented itself with state in struct dio that hangs off the bios.  I
> > imagine it'd still make sense to clean up the addresses/pages arguments
> > that feed that engine.  (And give another entry point that already has
> > bios for callers like loop, etc.)
> 
> Yeah, precisely. I think we can push the point at which pages are pinned at
> least a fair but higher than it is now, and if we can do that we definitely
> should be working with a generic "bag of pinned pages" struct - and much
> better to use struct bio than add another one. Bios may not be perfect but
> at least some of the block layer specific cruft can be gotten rid of (and
> is on my todo list)

How far up?  I've no problem with having that done in ->direct_IO()
(especially if it would take this mem_vec/mem_stream/whatever and
keep the code doing actual pinning and building an array of pages
outside of direct-io.c, allowing it to do different things for iovec-backed
and page-array-backed variants), but I really don't like the idea of
lifting that to callers of ->direct_IO(), let alone past them.

If nothing else, we do *not* want to pin the entire write request, so
lifting that to e.g. generic_file_aio_write() (or, worse, its callers)
wouldn't make sense.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

WARNING: multiple messages have this Message-ID (diff)
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Kent Overstreet <kmo@daterainc.com>
Cc: Zach Brown <zab@redhat.com>,
	Dave Kleikamp <dave.kleikamp@oracle.com>,
	Steve French <sfrench@samba.org>, Sage Weil <sage@inktank.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Jens Axboe <axboe@kernel.dk>,
	Anton Altaparmakov <anton@tuxera.com>,
	Mark Fasheh <mfasheh@suse.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	xfs@oss.sgi.com, Joel Becker <jlbec@evilplan.org>,
	Christoph Hellwig <hch@infradead.org>
Subject: Re: [RFC] unifying write variants for filesystems
Date: Tue, 4 Feb 2014 18:08:37 +0000	[thread overview]
Message-ID: <20140204180837.GJ10323@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CALJ65z=HhYnc1eD-Kpk0s=Eod6sHJq1jnJirUNc7-9s1rFV1HQ@mail.gmail.com>

On Tue, Feb 04, 2014 at 09:35:06AM -0800, Kent Overstreet wrote:
> > I think Kent is talking about what happens after the user addresses are
> > consumed.  Turning dio into more of a bio mapping and redirection engine
> > would use more of the bio machinery instead of the bits that dio has
> > implemented itself with state in struct dio that hangs off the bios.  I
> > imagine it'd still make sense to clean up the addresses/pages arguments
> > that feed that engine.  (And give another entry point that already has
> > bios for callers like loop, etc.)
> 
> Yeah, precisely. I think we can push the point at which pages are pinned at
> least a fair but higher than it is now, and if we can do that we definitely
> should be working with a generic "bag of pinned pages" struct - and much
> better to use struct bio than add another one. Bios may not be perfect but
> at least some of the block layer specific cruft can be gotten rid of (and
> is on my todo list)

How far up?  I've no problem with having that done in ->direct_IO()
(especially if it would take this mem_vec/mem_stream/whatever and
keep the code doing actual pinning and building an array of pages
outside of direct-io.c, allowing it to do different things for iovec-backed
and page-array-backed variants), but I really don't like the idea of
lifting that to callers of ->direct_IO(), let alone past them.

If nothing else, we do *not* want to pin the entire write request, so
lifting that to e.g. generic_file_aio_write() (or, worse, its callers)
wouldn't make sense.

  reply	other threads:[~2014-02-04 18:08 UTC|newest]

Thread overview: 82+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-12 18:14 [PATCH 0/5] splice: locking changes and code refactoring Christoph Hellwig
2013-12-12 18:14 ` Christoph Hellwig
2013-12-12 18:15 ` [PATCH 1/5] splice: move balance_dirty_pages_ratelimited into pipe_to_file Christoph Hellwig
2013-12-12 18:15   ` Christoph Hellwig
2013-12-12 18:15 ` [PATCH 2/5] splice: nest i_mutex outside pipe_lock Christoph Hellwig
2013-12-12 18:15   ` Christoph Hellwig
2013-12-12 18:15 ` [PATCH 3/5] splice: use splice_from_pipe in generic_file_splice_write Christoph Hellwig
2013-12-12 18:15   ` Christoph Hellwig
2013-12-12 18:15 ` [PATCH 4/5] xfs: fix splice_write locking Christoph Hellwig
2013-12-12 18:15   ` Christoph Hellwig
2013-12-12 18:15 ` [PATCH 5/5] splice: stop exporting splice_from_pipe implementation details Christoph Hellwig
2013-12-12 18:15   ` Christoph Hellwig
2014-01-13 14:14 ` [PATCH 0/5] splice: locking changes and code refactoring Christoph Hellwig
2014-01-13 14:14   ` Christoph Hellwig
2014-01-13 23:56   ` Al Viro
2014-01-13 23:56     ` Al Viro
2014-01-14 13:22     ` Christoph Hellwig
2014-01-14 13:22       ` Christoph Hellwig
2014-01-14 17:20       ` Al Viro
2014-01-14 17:20         ` Al Viro
2014-01-15 18:10         ` Al Viro
2014-01-15 18:10           ` Al Viro
2014-01-18  6:40         ` Al Viro
2014-01-18  7:22           ` Linus Torvalds
2014-01-18  7:22             ` Linus Torvalds
2014-01-18  7:46             ` Al Viro
2014-01-18  7:56               ` Al Viro
2014-01-18  7:56                 ` Al Viro
2014-01-18  8:27               ` Al Viro
2014-01-18  8:44                 ` David Miller
2014-01-18  8:44                   ` David Miller
2014-02-07 17:10                   ` Al Viro
2014-02-07 17:10                     ` Al Viro
2014-01-18 19:59               ` Linus Torvalds
2014-01-18 20:10                 ` Al Viro
2014-01-18 20:27                   ` Al Viro
2014-01-18 20:27                     ` Al Viro
2014-01-18 20:30                     ` Al Viro
2014-01-18 20:30                       ` Al Viro
2014-01-19  5:13                   ` [RFC] unifying write variants for filesystems Al Viro
2014-01-19  5:13                     ` Al Viro
2014-01-20 13:55                     ` Christoph Hellwig
2014-01-20 13:55                       ` Christoph Hellwig
2014-01-20 20:32                       ` Linus Torvalds
2014-01-20 20:32                         ` Linus Torvalds
2014-02-01 22:43                         ` Al Viro
2014-02-01 22:43                           ` Al Viro
2014-02-02  0:13                           ` Linus Torvalds
2014-02-02  2:02                             ` Al Viro
2014-02-02  2:02                               ` Al Viro
2014-02-02 19:21                           ` Al Viro
2014-02-02 19:21                             ` Al Viro
2014-02-02 19:23                             ` Al Viro
2014-02-02 19:23                               ` Al Viro
2014-02-03 14:41                             ` Miklos Szeredi
2014-02-03 14:41                               ` Miklos Szeredi
2014-02-03 15:33                               ` Al Viro
2014-02-03 15:33                                 ` Al Viro
2014-02-02 23:16                           ` Anton Altaparmakov
2014-02-02 23:16                             ` Anton Altaparmakov
2014-02-03 15:12                           ` Christoph Hellwig
2014-02-03 16:24                             ` Al Viro
2014-02-03 16:50                             ` Dave Kleikamp
2014-02-03 16:23                           ` Dave Kleikamp
2014-02-04 12:44                             ` Al Viro
2014-02-04 12:44                               ` Al Viro
2014-02-04 12:52                               ` Kent Overstreet
2014-02-04 12:52                                 ` Kent Overstreet
2014-02-04 15:17                                 ` Al Viro
2014-02-04 15:17                                   ` Al Viro
2014-02-04 17:27                                   ` Zach Brown
2014-02-04 17:35                                     ` Kent Overstreet
2014-02-04 18:08                                       ` Al Viro [this message]
2014-02-04 18:08                                         ` Al Viro
2014-02-04 18:00                                     ` Al Viro
2014-02-04 18:00                                       ` Al Viro
2014-02-04 18:33                                       ` Zach Brown
2014-02-04 18:36                                         ` Al Viro
2014-02-04 18:36                                           ` Al Viro
2014-02-05 19:58                                           ` Al Viro
2014-02-05 20:42                                             ` Zach Brown
2014-02-06  9:08                                             ` Kent Overstreet

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=20140204180837.GJ10323@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=anton@tuxera.com \
    --cc=axboe@kernel.dk \
    --cc=dave.kleikamp@oracle.com \
    --cc=hch@infradead.org \
    --cc=jlbec@evilplan.org \
    --cc=kmo@daterainc.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=mfasheh@suse.com \
    --cc=sage@inktank.com \
    --cc=sfrench@samba.org \
    --cc=torvalds@linux-foundation.org \
    --cc=xfs@oss.sgi.com \
    --cc=zab@redhat.com \
    /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.