On Sat, Oct 16, 2021 at 08:07:40PM +0100, Matthew Wilcox wrote:
> On Wed, Sep 22, 2021 at 11:08:58AM -0400, Johannes Weiner wrote:
> > mm/lru: Add folio LRU functions
> >
> > The LRU code is used by anon and file and not needed
> > for the filesystem API.
> >
> > And as discussed, there is generally no ambiguity of
> > tail pages on the LRU list.
>
> One of the assumptions you're making is that the current code is suitable
> for folios. One of the things that happens in this patch is:
>
> - update_lru_size(lruvec, lru, page_zonenum(page), thp_nr_pages(page));
> + update_lru_size(lruvec, lru, folio_zonenum(folio),
> + folio_nr_pages(folio));
>
> static inline long folio_nr_pages(struct folio *folio)
> {
> return compound_nr(&folio->page);
> }
>
> vs
>
> #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> static inline int thp_nr_pages(struct page *page)
> {
> VM_BUG_ON_PGFLAGS(PageTail(page), page);
> if (PageHead(page))
> return HPAGE_PMD_NR;
> return 1;
> }
> #else
> static inline int thp_nr_pages(struct page *page)
> {
> VM_BUG_ON_PGFLAGS(PageTail(page), page);
> return 1;
> }
> #endif
>
> So if you want to leave all the LRU code using pages, all the uses of
> thp_nr_pages() need to be converted to compound_nr(). Or maybe not all
> of them; I don't know which ones might be safe to leave as thp_nr_pages().
> That's one of the reasons I went with a whitelist approach.
All of them. The only compound pages that can exist on the LRUs are
THPs, and the only THP pages that can exist on the LRUs are
compound. There is no plausible scenario where those two functions
would disagree in the LRU code.
Or elsewhere in the kernel, for that matter. Where would
thp_nr_pages() returning compound_nr() ever be wrong? How else are we
implementing THPs? I'm not sure that would make sense.
