Re: [PATCH 6.12.y] mm: folio_may_be_lru_cached() unless folio_test_large()

[Sasha Levin <sashal@kernel.org>]

On Mon, Sep 22, 2025 at 10:49:31AM +0100, Will Deacon wrote:
>On Sun, Sep 21, 2025 at 09:05:35PM -0700, Hugh Dickins wrote:
>> On Sun, 21 Sep 2025, Greg KH wrote:
>> > On Sun, Sep 21, 2025 at 11:41:34AM -0400, Sasha Levin wrote:
>> > > From: Hugh Dickins <hughd@google.com>
>> > >
>> > > [ Upstream commit 2da6de30e60dd9bb14600eff1cc99df2fa2ddae3 ]
>> > >
>> > > mm/swap.c and mm/mlock.c agree to drain any per-CPU batch as soon as a
>> > > large folio is added: so collect_longterm_unpinnable_folios() just wastes
>> > > effort when calling lru_add_drain[_all]() on a large folio.
>> > >
>> > > But although there is good reason not to batch up PMD-sized folios, we
>> > > might well benefit from batching a small number of low-order mTHPs (though
>> > > unclear how that "small number" limitation will be implemented).
>> > >
>> > > So ask if folio_may_be_lru_cached() rather than !folio_test_large(), to
>> > > insulate those particular checks from future change.  Name preferred to
>> > > "folio_is_batchable" because large folios can well be put on a batch: it's
>> > > just the per-CPU LRU caches, drained much later, which need care.
>> > >
>> > > Marked for stable, to counter the increase in lru_add_drain_all()s from
>> > > "mm/gup: check ref_count instead of lru before migration".
>> > >
>> > > Link: https://lkml.kernel.org/r/57d2eaf8-3607-f318-e0c5-be02dce61ad0@google.com
>> > > Fixes: 9a4e9f3b2d73 ("mm: update get_user_pages_longterm to migrate pages allocated from CMA region")
>> > > Signed-off-by: Hugh Dickins <hughd@google.com>
>> > > Suggested-by: David Hildenbrand <david@redhat.com>
>> > > Acked-by: David Hildenbrand <david@redhat.com>
>> > > Cc: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
>> > > Cc: Axel Rasmussen <axelrasmussen@google.com>
>> > > Cc: Chris Li <chrisl@kernel.org>
>> > > Cc: Christoph Hellwig <hch@infradead.org>
>> > > Cc: Jason Gunthorpe <jgg@ziepe.ca>
>> > > Cc: Johannes Weiner <hannes@cmpxchg.org>
>> > > Cc: John Hubbard <jhubbard@nvidia.com>
>> > > Cc: Keir Fraser <keirf@google.com>
>> > > Cc: Konstantin Khlebnikov <koct9i@gmail.com>
>> > > Cc: Li Zhe <lizhe.67@bytedance.com>
>> > > Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
>> > > Cc: Peter Xu <peterx@redhat.com>
>> > > Cc: Rik van Riel <riel@surriel.com>
>> > > Cc: Shivank Garg <shivankg@amd.com>
>> > > Cc: Vlastimil Babka <vbabka@suse.cz>
>> > > Cc: Wei Xu <weixugc@google.com>
>> > > Cc: Will Deacon <will@kernel.org>
>> > > Cc: yangge <yangge1116@126.com>
>> > > Cc: Yuanchu Xie <yuanchu@google.com>
>> > > Cc: Yu Zhao <yuzhao@google.com>
>> > > Cc: <stable@vger.kernel.org>
>> > > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>> > > [ adapted to drain_allow instead of drained ]
>> > > Signed-off-by: Sasha Levin <sashal@kernel.org>
>> > > ---
>> >
>> > Does not apply as it conflicts with the other mm changes you sent right
>> > before this one :(
>>
>> Thanks for grabbing all these, I'm sorry they are troublesome.
>>
>> Though I'm usually able to work out what to do from the FAILED mails,
>> in this case I'd just be guessing without the full contexts.
>> So I'll wait until I see what goes into the various branches of
>> linux-stable-rc.git before checking and adjusting where necessary.
>>
>> (As usual, I'll tend towards minimal change, where Sasha tends
>> towards maximal backporting of encroaching mods: we may disagree.)
>>
>> The main commits contributing to the pinning failures that Will Deacon
>> reported were commits going into 5.18 and 6.11.  So although I stand
>> by my Fixes tag, I'm likely to conclude that 5.15 and 5.10 and 5.4
>> are better left stable without any of it.
>
>That suits me. 6.1, 6.6 and 6.12 are the main ones that I'm concerned
>with from the Android side.

I'll hold off on backports then :)

-- 
Thanks,
Sasha