Re: [PATCH RFC] mm/huge_memory: eliminate reference-counted huge zero folio

[David Hildenbrand (Arm)]

On 7/28/26 15:06, Lorenzo Stoakes (ARM) wrote:
> The reference-counted huge zero folio is problematic - it's prone to subtle
> races, it can introduce allocation latency and it is confusing and
> complicated code.

Just a note that the subject is misleading: the huge zero folio is always
refcounted (e.g., GUP must take references), it's just that the persistent huge
zero folio never drops the refcount to 0 to free it.

What you probably mean is "mm/huge_memory: eliminate dynamically allocated huge
zero folio".

If we go down that path here, we can also teach GUP to not take a reference on
the huge zero folio anymore on the FOLL_PIN path, similar to how we handle the
zero folio.

See the occurrences of is_zero_folio() in mm/gup.c.

The reason we do it for now for FOLL_PIN is that a remote pin might outlive the
process, meaning the huge folio could otherwise get freed by the shrinker even
though someone still holds a reference. Bad. So that would no longer apply if
the huge zero folio can no longer get freed.


I recall there was a discussion (dropping dynamically allocated huge zero folio)
on this topic while upstreaming the persistent huge zero folio.

I don't have time right now to dig, but it would be worthwhile to look at that
history if there was a good reason to keep it buried in that discussion.

-- 
Cheers,

David