[PATCH 10/13] mm: open code readahead in filemap_new_page

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Calling filemap_make_page_uptodate right after filemap_readpage in
filemap_new_page is rather counterintuitive.  The call is in fact
only needed to issue async readahead, and is guaranteed to return
just after that because the page is uptodate.  Just open code the
readahead related parts of filemap_make_page_uptodate instead.

Signed-off-by: Christoph Hellwig <hch@xxxxxx>
---
 mm/filemap.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/mm/filemap.c b/mm/filemap.c
index 5f4937715689e7..000f75cd359d1c 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -2309,9 +2309,14 @@ static int filemap_new_page(struct kiocb *iocb, struct iov_iter *iter,
 	error = filemap_readpage(iocb, *page);
 	if (error)
 		goto put_page;
-	error = filemap_make_page_uptodate(iocb, iter, *page, index, true);
-	if (error)
-		goto put_page;
+	if (PageReadahead(*page)) {
+		error = -EAGAIN;
+		if (iocb->ki_flags & IOCB_NOIO)
+			goto put_page;
+		page_cache_async_readahead(mapping, &iocb->ki_filp->f_ra,
+				iocb->ki_filp, *page, index,
+				(iter->count + PAGE_SIZE - 1) >> PAGE_SHIFT);
+	}
 	return 0;
 put_page:
 	put_page(*page);
-- 
2.28.0




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux