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:

quoted

      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.