Re: [PATCH] mm/fadvise: avoid remote LRU drain for mapped folio failures
From: Fujunjie
Date: Mon May 11 2026 - 02:47:12 EST
On 5/11/2026 1:47 PM, David Hildenbrand (Arm) wrote:
>> -long mapping_evict_folio(struct address_space *mapping, struct folio *folio)
>> +static long __mapping_evict_folio(struct address_space *mapping,
>> + struct folio *folio, bool *lru_refs)
>> {
>> + if (lru_refs)
>> + *lru_refs = false;
>> /* The page may have been truncated before it was locked */
>> if (!mapping)
>> return 0;
>> @@ -331,14 +323,38 @@ long mapping_evict_folio(struct address_space *mapping, struct folio *folio)
>> return 0;
>> /* The refcount will be elevated if any page in the folio is mapped */
>> if (folio_ref_count(folio) >
>> - folio_nr_pages(folio) + folio_has_private(folio) + 1)
>> + folio_nr_pages(folio) + folio_has_private(folio) + 1) {
>> + /*
>> + * A remote LRU drain can only help with extra references on
>> + * otherwise evictable folios. Mapped folios also have an
>> + * elevated refcount, but draining LRU caches cannot unmap them.
>> + */
>> + if (lru_refs && !folio_mapped(folio))
>> + *lru_refs = true;
>
> How can you conclude that it's a LRU refs? Could also just be something trivial
> like a remaining GUP reference, or am I wrong?
>
You're right. The elevated refcount does not prove that the extra
reference is from a remote LRU batch; it could be GUP or another transient
reference.
The intent was to use this as an approximate filter: avoid the remote
drain for failures where it clearly cannot help, such as mapped folios,
rather than to prove the exact source of the extra reference.
"lru_refs" is too strong or misleading as a name. For v2 I will take
Matthew's suggestion into account as well: avoid adding
__mapping_evict_folio(), do the folio_mapped() test in
mapping_try_invalidate(), and think more carefully about where the
fallback boundary should be. I will also use naming that describes the
decision more accurately rather than implying that the extra reference
has been proven to be an LRU-batch reference.