From: Dave Kleikamp <dave.kleikamp@oracle.com>
To: "Maxim V. Patlasov" <mpatlasov@parallels.com>
Cc: Zach Brown <zab@zabbo.net>, Jeff Moyer <jmoyer@redhat.com>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH v2 15/21] loop: use aio to perform io on the underlying file
Date: Fri, 20 Apr 2012 12:19:33 -0500 [thread overview]
Message-ID: <4F919AA5.2030402@oracle.com> (raw)
In-Reply-To: <4F918B64.5030602@parallels.com>
On 04/20/2012 11:14 AM, Maxim V. Patlasov wrote:
> On 04/20/2012 07:57 PM, Dave Kleikamp wrote:
>>> So yeah, I'd agree that the loop code should be reworked a bit so that
>>> both the filebacked and aio methods call vfs_sync() when they see
>>> REQ_FLUSH.
>> It's an easy fix. I don't anticipate that it will hurt performance too
>> badly.
>
> Two questions:
>
> 1. Could we use fdatasync there? (otherwise it can hurt performance very
> badly)
I don't see why not.
> 2. vfs_sync() is synchronous. loop_thread() will be blocked till it's
> completed. Would it be better to perform vfs_sync in another thread (to
> allow other bio-s in loop queue proceed)? Also, if there are more than
> one REQ_FLUSH bio in lo->lo_bio_list, we could call vfs_sync() only
> once. Make sense?
If more than one REQ_FLUSH bio is in the list, they should be performed
in order. We must call vfs_fsync() between each of them to guarantee that.
A less complex tradeoff would be to move the vfs_fsync() call to
loop_make_request() so it is called in the context of the thread making
the request. That would make those threads requesting ordered IO to pay
the price while others would be able to proceed.
This is something I can re-visit. I don't want to hold up progress on
the patchset for something that can be improved later.
>
> Thanks,
> Maxim
next prev parent reply other threads:[~2012-04-20 17:19 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-30 15:43 [RFC PATCH v2 00/21] loop: Issue O_DIRECT aio using bio_vec Dave Kleikamp
2012-03-30 15:43 ` [RFC PATCH v2 01/21] iov_iter: move into its own file Dave Kleikamp
2012-03-30 15:43 ` [RFC PATCH v2 02/21] iov_iter: add copy_to_user support Dave Kleikamp
2012-03-30 15:43 ` [RFC PATCH v2 03/21] fuse: convert fuse to use iov_iter_copy_[to|from]_user Dave Kleikamp
2012-03-30 15:43 ` [RFC PATCH v2 04/21] iov_iter: hide iovec details behind ops function pointers Dave Kleikamp
2012-03-30 15:43 ` [RFC PATCH v2 05/21] iov_iter: add bvec support Dave Kleikamp
2012-03-30 15:43 ` [RFC PATCH v2 06/21] iov_iter: add a shorten call Dave Kleikamp
2012-03-30 15:43 ` [RFC PATCH v2 07/21] iov_iter: let callers extract iovecs and bio_vecs Dave Kleikamp
2012-03-30 15:43 ` [RFC PATCH v2 08/21] dio: create a dio_aligned() helper function Dave Kleikamp
2012-03-30 15:43 ` [RFC PATCH v2 09/21] dio: Convert direct_IO to use iov_iter Dave Kleikamp
2012-03-30 15:43 ` [RFC PATCH v2 10/21] dio: add bio_vec support to __blockdev_direct_IO() Dave Kleikamp
2012-03-30 15:43 ` [RFC PATCH v2 11/21] fs: pull iov_iter use higher up the stack Dave Kleikamp
2012-03-30 15:43 ` [RFC PATCH v2 12/21] aio: add aio_kernel_() interface Dave Kleikamp
2012-03-30 15:43 ` [RFC PATCH v2 13/21] aio: add aio support for iov_iter arguments Dave Kleikamp
2012-03-30 15:43 ` [RFC PATCH v2 14/21] bio: add bvec_length(), like iov_length() Dave Kleikamp
2012-03-30 15:43 ` [RFC PATCH v2 15/21] loop: use aio to perform io on the underlying file Dave Kleikamp
2012-04-20 14:48 ` Maxim V. Patlasov
2012-04-20 15:09 ` Dave Kleikamp
2012-04-20 15:20 ` Jeff Moyer
2012-04-20 15:52 ` Zach Brown
2012-04-20 15:57 ` Dave Kleikamp
2012-04-20 16:14 ` Maxim V. Patlasov
2012-04-20 17:19 ` Dave Kleikamp [this message]
2012-04-20 17:37 ` Maxim V. Patlasov
2012-04-20 16:35 ` Jeff Moyer
2012-04-20 17:48 ` Zach Brown
2012-04-20 16:14 ` Dave Kleikamp
2012-03-30 15:43 ` [RFC PATCH v2 16/21] ext3: add support for .read_iter and .write_iter Dave Kleikamp
2012-03-30 15:43 ` [RFC PATCH v2 17/21] ocfs2: add support for read_iter, write_iter, and direct_IO_bvec Dave Kleikamp
2012-03-30 15:43 ` [RFC PATCH v2 18/21] ext4: add support for read_iter and write_iter Dave Kleikamp
2012-04-02 18:42 ` Ted Ts'o
2012-04-02 22:45 ` Dave Kleikamp
2012-04-03 0:11 ` Dave Kleikamp
2012-03-30 15:43 ` [RFC PATCH v2 19/21] nfs: add support for read_iter, write_iter Dave Kleikamp
2012-03-30 15:43 ` [RFC PATCH v2 20/21] btrfs: add support for read_iter and write_iter Dave Kleikamp
2012-03-30 15:43 ` [RFC PATCH v2 21/21] fs: add read_iter and write_iter to more file systems Dave Kleikamp
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=4F919AA5.2030402@oracle.com \
--to=dave.kleikamp@oracle.com \
--cc=jmoyer@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mpatlasov@parallels.com \
--cc=zab@zabbo.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 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).