From: Jens Axboe <axboe@kernel.dk>
To: Matthew Wilcox <willy@infradead.org>
Cc: io-uring@vger.kernel.org, linux-mm@kvack.org,
linux-fsdevel@vger.kernel.org, linux-aio@kvack.org
Subject: Re: [PATCH 0/2] Close a hole where IOCB_NOWAIT reads could sleep
Date: Sat, 24 Jul 2021 13:46:03 -0600 [thread overview]
Message-ID: <5b0e9558-0bb0-c2b0-2125-b8d33a1c3360@kernel.dk> (raw)
In-Reply-To: <YPxaXE0mf26aqy/O@casper.infradead.org>
On 7/24/21 12:22 PM, Matthew Wilcox wrote:
> On Sun, Jul 11, 2021 at 07:44:07PM -0600, Jens Axboe wrote:
>> On 7/11/21 9:09 AM, Matthew Wilcox (Oracle) wrote:
>>> I noticed a theoretical case where an IOCB_NOWAIT read could sleep:
>>>
>>> filemap_get_pages
>>> filemap_get_read_batch
>>> page_cache_sync_readahead
>>> page_cache_sync_ra
>>> ondemand_readahead
>>> do_page_cache_ra
>>> page_cache_ra_unbounded
>>> gfp_t gfp_mask = readahead_gfp_mask(mapping);
>>> memalloc_nofs_save()
>>> __page_cache_alloc(gfp_mask);
>>>
>>> We're in a nofs context, so we're not going to start new IO, but we might
>>> wait for writeback to complete. We generally don't want to sleep for IO,
>>> particularly not for IO that isn't related to us.
>>>
>>> Jens, can you run this through your test rig and see if it makes any
>>> practical difference?
>>
>> You bet, I'll see if I can trigger this condition and verify we're no
>> longer blocking on writeback. Thanks for hacking this up.
>
> Did you have any success yet?
Sorry forgot to report back - I did run some testing last week, and
didn't manage to make it hit the blocking condition. Did various
read/write mix on the same file, made sure there was memory pressure,
etc. I'll give it another go, please let me know if you have an idea on
how to make this easier to hit... I know it's one of those things that
you hit all the time in certain workloads (hence why I would love to see
it get fixed), but I just didn't manage to provoke it when I tried.
--
Jens Axboe
prev parent reply other threads:[~2021-07-24 19:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-11 15:09 [PATCH 0/2] Close a hole where IOCB_NOWAIT reads could sleep Matthew Wilcox (Oracle)
2021-07-11 15:09 ` [PATCH 1/2] mm/readahead: Add gfp_flags to ractl Matthew Wilcox (Oracle)
2021-07-12 11:34 ` Christoph Hellwig
2021-07-12 14:37 ` Matthew Wilcox
2021-07-11 15:09 ` [PATCH 2/2] mm/filemap: Prevent waiting for memory for NOWAIT reads Matthew Wilcox (Oracle)
2021-07-12 1:44 ` [PATCH 0/2] Close a hole where IOCB_NOWAIT reads could sleep Jens Axboe
2021-07-24 18:22 ` Matthew Wilcox
2021-07-24 19:46 ` 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=5b0e9558-0bb0-c2b0-2125-b8d33a1c3360@kernel.dk \
--to=axboe@kernel.dk \
--cc=io-uring@vger.kernel.org \
--cc=linux-aio@kvack.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--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 NNTP newsgroup(s).