Re: [PATCH] mm/fadvise: avoid remote LRU drain for mapped folio failures

[Fujunjie]

On 5/11/2026 2:14 AM, Matthew Wilcox wrote:
> On Fri, May 08, 2026 at 04:35:49PM -0700, Andrew Morton wrote:
>> On Wed,  6 May 2026 11:23:59 +0000 fujunjie <fujunjie1@xxxxxx> wrote:
>>
>>> generic_fadvise(POSIX_FADV_DONTNEED) drains the local LRU batch and
>>> then tries to invalidate the requested page-cache range. If any folio
>>> could not be evicted, it assumes that a remote per-cpu LRU batch might
>>> be pinning the folio, calls lru_add_drain_all(), and walks the mapping
>>> again.
>>>
>>> ...
>>>
>>> Teach the folio eviction path to report whether a failure hit the
>>> existing refcount check on a clean, unmapped folio. Only request the
>>> global drain for that case. This preserves the existing fallback for
>>> failures that a remote LRU drain can plausibly fix, while avoiding it
>>> for failure reasons that a remote drain is not expected to resolve.
>>>
>>
>> Thanks.  AI reviw asked one question:
>> 	https://sashiko.dev/#/patchset/tencent_DEDC345B4071ED3C9B293ACD437B9C8DBC0A@xxxxxx
> 
> That's a pretty poor quality review.
> 
> My question is why we do this bizarre thing of switching between an
> unsigned long and a bool pointer.
> 
> I would also avoid creating __mapping_evict_folio() and do the test for
> folio_mapped() in mapping_try_invalidate().  It all feels a bit weird
> (both this patch and the original code), and probably needs a lot more
> thought, which I'm not in a position to do right now.

Thanks,agreed.

The count is not really used as a count by the fadvise path; it only gates
whether to do one remote drain and retry. Also, adding
__mapping_evict_folio() just to pass back this bit makes the interface more
awkward than it needs to be.

I will rework this for v2 to keep mapping_evict_folio() unchanged and do
the folio_mapped() check in mapping_try_invalidate(), as you suggested.
I will also think more carefully about the fallback boundary and use less
misleading naming, since an elevated refcount does not by itself prove a
remote LRU-batch reference.