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

[Matthew Wilcox]

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.