From: Johannes Weiner <hannes@cmpxchg.org>
To: Josef Bacik <josef@toxicpanda.com>
Cc: kernel-team@fb.com, linux-kernel@vger.kernel.org, tj@kernel.org,
david@fromorbit.com, akpm@linux-foundation.org,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
riel@redhat.com, jack@suse.cz
Subject: Re: [PATCH 2/4] filemap: kill page_cache_read usage in filemap_fault
Date: Wed, 5 Dec 2018 13:52:09 -0800 [thread overview]
Message-ID: <20181205215209.GA13938@cmpxchg.org> (raw)
In-Reply-To: <20181130195812.19536-3-josef@toxicpanda.com>
On Fri, Nov 30, 2018 at 02:58:10PM -0500, Josef Bacik wrote:
> If we do not have a page at filemap_fault time we'll do this weird
> forced page_cache_read thing to populate the page, and then drop it
> again and loop around and find it. This makes for 2 ways we can read a
> page in filemap_fault, and it's not really needed. Instead add a
> FGP_FOR_MMAP flag so that pagecache_get_page() will return a unlocked
> page that's in pagecache. Then use the normal page locking and readpage
> logic already in filemap_fault. This simplifies the no page in page
> cache case significantly.
>
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
That's a great simplification. Looks correct to me.
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
next prev parent reply other threads:[~2018-12-05 21:52 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-30 19:58 [PATCH 0/4][V4] drop the mmap_sem when doing IO in the fault path Josef Bacik
2018-11-30 19:58 ` [PATCH 1/4] mm: infrastructure for page fault page caching Josef Bacik
2018-12-04 22:49 ` Andrew Morton
2018-11-30 19:58 ` [PATCH 2/4] filemap: kill page_cache_read usage in filemap_fault Josef Bacik
2018-12-05 21:52 ` Johannes Weiner [this message]
2018-12-07 9:57 ` Jan Kara
2018-12-07 10:37 ` Jan Kara
2018-11-30 19:58 ` [PATCH 3/4] filemap: drop the mmap_sem for all blocking operations Josef Bacik
2018-12-04 22:50 ` Andrew Morton
2018-12-05 22:23 ` Johannes Weiner
2018-12-07 11:01 ` Jan Kara
2018-12-10 18:44 ` Josef Bacik
2018-12-11 9:40 ` Jan Kara
2018-12-11 16:08 ` Josef Bacik
2018-12-11 16:38 ` Jan Kara
2018-11-30 19:58 ` [PATCH 4/4] mm: use the cached page for filemap_fault Josef Bacik
2018-12-04 22:50 ` Andrew Morton
2018-12-05 14:58 ` Josef Bacik
2018-12-07 11:03 ` Jan Kara
2018-12-04 22:49 ` [PATCH 0/4][V4] drop the mmap_sem when doing IO in the fault path Andrew Morton
2018-12-06 22:24 ` Dave Chinner
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=20181205215209.GA13938@cmpxchg.org \
--to=hannes@cmpxchg.org \
--cc=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=jack@suse.cz \
--cc=josef@toxicpanda.com \
--cc=kernel-team@fb.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=riel@redhat.com \
--cc=tj@kernel.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.