From: Goldwyn Rodrigues <rgoldwyn@suse.de>
To: Matthew Wilcox <willy@infradead.org>
Cc: linux-fsdevel@vger.kernel.org, jack@suse.com, hch@infradead.org,
linux-block@vger.kernel.org, linux-btrfs@vger.kernel.org,
linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org,
sagi@grimberg.me, avi@scylladb.com, axboe@kernel.dk,
linux-api@vger.kernel.org, Goldwyn Rodrigues <rgoldwyn@suse.com>
Subject: Re: [PATCH 3/8] nowait aio: return if direct write will trigger writeback
Date: Thu, 16 Mar 2017 08:46:27 -0500 [thread overview]
Message-ID: <963ce6bd-730a-76e5-4d7e-d63552c94ff9@suse.de> (raw)
In-Reply-To: <20170316130824.GF4033@bombadil.infradead.org>
On 03/16/2017 08:08 AM, Matthew Wilcox wrote:
> On Wed, Mar 15, 2017 at 04:51:02PM -0500, Goldwyn Rodrigues wrote:
>> This introduces a new function filemap_range_has_page() which
>> returns true if the file's mapping has a page within the range
>> mentioned.
>
> I thought you were going to replace this patch with one that starts
> writeback for these pages but does not wait for them?
>
As mentioned by Jan, Flags to filemap_write_and_wait_range are
unnecessarily complicated. The AIO-DIO API users who eye for performance
usually are careful with page writes/evictions. As a fallback, they can
(and should) go the wait route (without IOCB_RW_FLAG_NOWAIT).
Finally, my take on this is that we don't want to perform tasks for a
following system call, which may or may not immediately follow the
current one. May not, because an application (DB) will offload the task
from the CPU thread to the I/O thread in case of -EAGAIN. A system call
should be complete in itself (and do the minimum, what is asked).
--
Goldwyn
next prev parent reply other threads:[~2017-03-16 13:46 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-15 21:50 [PATCH 0/8 v3] No wait AIO Goldwyn Rodrigues
2017-03-15 21:50 ` Goldwyn Rodrigues
2017-03-15 21:51 ` [PATCH 1/8] nowait aio: Introduce IOCB_RW_FLAG_NOWAIT Goldwyn Rodrigues
2017-03-15 21:51 ` [PATCH 2/8] nowait aio: Return if cannot get hold of i_rwsem Goldwyn Rodrigues
2017-03-15 21:51 ` [PATCH 3/8] nowait aio: return if direct write will trigger writeback Goldwyn Rodrigues
2017-03-16 13:08 ` Matthew Wilcox
2017-03-16 13:46 ` Goldwyn Rodrigues [this message]
2017-03-16 13:20 ` Matthew Wilcox
2017-03-16 13:46 ` Goldwyn Rodrigues
2017-03-16 13:46 ` Goldwyn Rodrigues
2017-03-15 21:51 ` [PATCH 4/8] nowait-aio: Introduce IOMAP_NOWAIT Goldwyn Rodrigues
2017-03-15 21:51 ` [PATCH 5/8] nowait aio: return on congested block device Goldwyn Rodrigues
2017-03-16 14:33 ` Jens Axboe
2017-03-16 14:33 ` Jens Axboe
2017-03-17 2:03 ` Ming Lei
2017-03-17 12:23 ` Goldwyn Rodrigues
2017-03-24 11:32 ` Goldwyn Rodrigues
2017-03-24 11:32 ` Goldwyn Rodrigues
2017-03-24 14:39 ` Jens Axboe
2017-03-16 21:31 ` Dave Chinner
2017-03-16 21:31 ` Dave Chinner
2017-03-17 12:23 ` Goldwyn Rodrigues
2017-03-20 17:33 ` Jan Kara
2017-03-15 21:51 ` [PATCH 6/8] nowait aio: ext4 Goldwyn Rodrigues
2017-03-15 21:51 ` [PATCH 7/8] nowait aio: xfs Goldwyn Rodrigues
2017-03-15 21:51 ` [PATCH 8/8] nowait aio: btrfs Goldwyn Rodrigues
-- strict thread matches above, loose matches on Subject: below --
2017-05-09 12:22 [PATCH 0/8 v7] No wait AIO Goldwyn Rodrigues
2017-05-09 12:22 ` [PATCH 3/8] nowait aio: return if direct write will trigger writeback Goldwyn Rodrigues
2017-05-11 7:42 ` Christoph Hellwig
2017-04-14 12:02 [PATCH 0/8 v6] No wait AIO Goldwyn Rodrigues
2017-04-14 12:02 ` [PATCH 3/8] nowait aio: return if direct write will trigger writeback Goldwyn Rodrigues
2017-04-03 18:52 [PATCH 0/8 v4] No wait AIO Goldwyn Rodrigues
2017-04-03 18:53 ` [PATCH 3/8] nowait aio: return if direct write will trigger writeback Goldwyn Rodrigues
2017-02-28 23:36 [PATCH 0/8 v2] Non-blocking AIO Goldwyn Rodrigues
2017-02-28 23:36 ` [PATCH 3/8] nowait aio: return if direct write will trigger writeback Goldwyn Rodrigues
2017-03-01 3:46 ` Matthew Wilcox
2017-03-01 15:38 ` Christoph Hellwig
2017-03-02 10:38 ` Jan Kara
2017-03-02 14:12 ` Matthew Wilcox
2017-03-02 15:22 ` Jan Kara
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=963ce6bd-730a-76e5-4d7e-d63552c94ff9@suse.de \
--to=rgoldwyn@suse.de \
--cc=avi@scylladb.com \
--cc=axboe@kernel.dk \
--cc=hch@infradead.org \
--cc=jack@suse.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=rgoldwyn@suse.com \
--cc=sagi@grimberg.me \
--cc=willy@infradead.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.