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
