Messages in this thread | ![/](/images/icornerl.gif) | | Date | Sat, 7 Jan 2023 15:11:48 +0000 | From | Matthew Wilcox <> | Subject | Re: [PATCH v5 1/3] mm: Merge folio_has_private()/filemap_release_folio() call pairs |
| |
On Thu, Dec 22, 2022 at 03:02:02PM +0000, David Howells wrote: > Make filemap_release_folio() check folio_has_private(). Then, in most > cases, where a call to folio_has_private() is immediately followed by a > call to filemap_release_folio(), we can get rid of the test in the pair. > > The same is done to page_has_private()/try_to_release_page() call pairs.
This line is now obsolete.
> There are a couple of sites in mm/vscan.c that this can't so easily be > done. In shrink_folio_list(), there are actually three cases (something > different is done for incompletely invalidated buffers), but > filemap_release_folio() elides two of them. > > In shrink_active_list(), we don't have have the folio lock yet, so the > check allows us to avoid locking the page unnecessarily. > > A wrapper function to check if a folio needs release is provided for those > places that still need to do it in the mm/ directory. This will acquire > additional parts to the condition in a future patch. > > After this, the only remaining caller of folio_has_private() outside of mm/ > is a check in fuse.
But there are a few remaining places which check page_has_private(). I think they're all wrong and should be PagePrivate(), but I'll look at them more next week.
| ![\](/images/icornerr.gif) |