[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181207095750.GC13008@quack2.suse.cz>
Date: Fri, 7 Dec 2018 10:57:50 +0100
From: Jan Kara <jack@...e.cz>
To: Josef Bacik <josef@...icpanda.com>
Cc: kernel-team@...com, hannes@...xchg.org,
linux-kernel@...r.kernel.org, tj@...nel.org, david@...morbit.com,
akpm@...ux-foundation.org, linux-fsdevel@...r.kernel.org,
linux-mm@...ck.org, riel@...hat.com, jack@...e.cz
Subject: Re: [PATCH 2/4] filemap: kill page_cache_read usage in filemap_fault
On Fri 30-11-18 14:58:10, 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@...icpanda.com>
Thanks for the patch. I like the simplification but I think it could be
even improved... see below.
> @@ -2449,9 +2426,11 @@ vm_fault_t filemap_fault(struct vm_fault *vmf)
> count_memcg_event_mm(vmf->vma->vm_mm, PGMAJFAULT);
> ret = VM_FAULT_MAJOR;
> retry_find:
> - page = find_get_page(mapping, offset);
> + page = pagecache_get_page(mapping, offset,
> + FGP_CREAT|FGP_FOR_MMAP,
> + vmf->gfp_mask);
> if (!page)
> - goto no_cached_page;
> + return vmf_error(-ENOMEM);
So why don't you just do:
page = pagecache_get_page(mapping, offset,
FGP_CREAT | FGP_LOCK, vmf->gfp_mask);
if (!page)
return vmf_error(-ENOMEM);
goto check_uptodate;
where check_uptodate would be a label before 'PageUptodate' check?
Then you don't have to introduce new flag for pagecache_get_page() and you
also don't have to unlock and then lock again the page... And you can still
delete all the code you've deleted.
Honza
--
Jan Kara <jack@...e.com>
SUSE Labs, CR
Powered by blists - more mailing lists