[lkml]   [2020]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v2 12/12] mm/filemap: Return only head pages from find_get_entries
On Wed 30-09-20 13:36:37, Matthew Wilcox wrote:
> On Wed, Sep 30, 2020 at 02:15:12PM +0200, Jan Kara wrote:
> > On Mon 14-09-20 14:00:42, Matthew Wilcox (Oracle) wrote:
> > > All callers now expect head (and base) pages, and can handle multiple
> > > head pages in a single batch, so make find_get_entries() behave that way.
> > > Also take the opportunity to make it use the pagevec infrastructure
> > > instead of open-coding how pvecs behave. This has the side-effect of
> > > being able to append to a pagevec with existing contents, although we
> > > don't make use of that functionality anywhere yet.
> > >
> > > Signed-off-by: Matthew Wilcox (Oracle) <>
> >
> > Looks good to me. You can add:
> >
> > Reviewed-by: Jan Kara <>
> >
> > I'm just curious: What has happened to pagevec_lookup_entries() call in
> > invalidate_inode_pages2_range()? Your series appears to be based on a tree
> > where the call already does not exist...
> That went away in patch 10 of this series.

Ah, I see. Thanks. Then I'm somewhat wondering is really
invalidate_inode_pages2_range() safe for THP head pages? At least the:

unmap_mapping_pages(mapping, index, 1, false);

doesn't look adequate for THP head pages... do_launder_page() is also
doubtful but probably currently OK because THPs cannot be dirty at this
moment. But how about THPs that are partialy inside start-end range? So far
the function didn't care because it was operating on page basis so it
didn't care but now it is probably relevant... At least it would warrant a
comment in some changelog if you are convinced everything is safe.


Jan Kara <>

 \ /
  Last update: 2020-09-30 19:09    [W:0.054 / U:7.568 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site