From: Jens Axboe <axboe@kernel.dk>
To: Matthew Wilcox <willy@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org,
Goldwyn Rodrigues <rgoldwyn@suse.com>,
Christoph Hellwig <hch@lst.de>, Jan Kara <jack@suse.cz>,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] mm/filemap: invalidating pages is still necessary when io with IOCB_NOWAIT
Date: Thu, 23 May 2024 15:17:57 -0600 [thread overview]
Message-ID: <359117d3-20e3-4c1b-a426-8ec1391ffec4@kernel.dk> (raw)
In-Reply-To: <Zk-w5n769fyZWTYC@casper.infradead.org>
On 5/23/24 3:11 PM, Matthew Wilcox wrote:
> On Thu, May 23, 2024 at 01:08:02PM -0700, Andrew Morton wrote:
>> On Mon, 13 May 2024 21:23:39 +0800 Liu Wei <liuwei09@cestc.cn> wrote:
>>
>>> After commit (6be96d3ad3 fs: return if direct I/O will trigger writeback),
>>> when we issuing AIO with direct I/O and IOCB_NOWAIT on a block device, the
>>> process context will not be blocked.
>>>
>>> However, if the device already has page cache in memory, EAGAIN will be
>>> returned. And even when trying to reissue the AIO with direct I/O and
>>> IOCB_NOWAIT again, we consistently receive EAGAIN.
>>>
>>> Maybe a better way to deal with it: filemap_fdatawrite_range dirty pages
>>> with WB_SYNC_NONE flag, and invalidate_mapping_pages unmapped pages at
>>> the same time.
>>
>> Can't userspace do this? If EAGAIN, sync the fd and retry the IO?
>
> I don't think that it can, because the pages will still be there, even
> if now clean? I think the idea was to punt to a worker thread which
> could sleep and retry without NOWAIT. But let's see what someone
> involved in this patch has to say about the intent.
Right, the idea is that if you get -EAGAIN, a non-blocking attempt
wasn't possible. You'd need to retry from somewhere where you CAN block.
Any issuer very much can do that, whether it's in-kernel or not.
It'd be somewhat fragile to make assumptions on what can cause the
-EAGAIN and try to rectify them, and then try again with IOCB_NOWAIT.
--
Jens Axboe
prev parent reply other threads:[~2024-05-23 21:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20240513132339.26269-1-liuwei09@cestc.cn>
2024-05-23 21:08 ` [PATCH] mm/filemap: invalidating pages is still necessary when io with IOCB_NOWAIT Matthew Wilcox
2024-05-23 21:16 ` Jens Axboe
2024-05-27 10:09 ` Liu Wei
2024-05-27 15:36 ` Jens Axboe
2024-05-30 2:33 ` Liu Wei
[not found] ` <20240523130802.730d2790b8e5f691871575c0@linux-foundation.org>
2024-05-23 21:11 ` Matthew Wilcox
2024-05-23 21:17 ` Jens Axboe [this message]
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=359117d3-20e3-4c1b-a426-8ec1391ffec4@kernel.dk \
--to=axboe@kernel.dk \
--cc=akpm@linux-foundation.org \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rgoldwyn@suse.com \
--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 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 read-only IMAP folder(s) and NNTP newsgroup(s).