Re: [PATCH 04/25] mm/fbatch: lru bit set, no extra ref, while folio on per-cpu fbatch

Next message: Krzysztof Kozlowski: "Re: [PATCH v4 1/7] dt-bindings: phy: Add PHY_TYPE_DSI and PHY_TYPE_CSI definitions"
Previous message: Pu Lehui: "Re: [PATCH bpf v2] bpf: Fix UAF due to concurrent consumption of waiting_for_gp_ttrace"
In reply to: Hugh Dickins: "[PATCH 04/25] mm/fbatch: lru bit set, no extra ref, while folio on per-cpu fbatch"
Next in thread: Hugh Dickins: "Re: [PATCH 04/25] mm/fbatch: lru bit set, no extra ref, while folio on per-cpu fbatch"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

From: Kiryl Shutsemau

Date: Thu Aug 27 2026 - 07:46:27 EST

On Mon, Aug 24, 2026 at 07:01:20AM -0700, Hugh Dickins wrote:
> Treat folios on a per-cpu fbatch as if they were already on the lruvec:
> with PG_lru set, without holding an extra reference. This will enable
> the removal of most lru_add_drain() and lru_add_drain_all() calls soon.
>
> Recognize such a folio by 0x02 set in the folio->lru.next pointer by
> folio_add_lru().

Hm. pfmemalloc (__GFP_MEMALLOC) thingy already claims the bit. Is it
safe because such memory is never on LRU?

Are pfmemalloc and PG_lru mutually exclusive?

Do we want to be explicit about this? Like, folio/page_is_pfmemalloc()
shouldn't return true for PG_lru folios/pages or something.

--
Kiryl Shutsemau / Kirill A. Shutemov