No, Linux does not pre-zero pages in the background, at least on x86 and x86-64. Not-present faults on anonymous VMAs are handled by do_anonymous_page() in mm/

No, Linux does not pre-zero pages in the background, at least on x86 and x86-64. Not-present faults on anonymous VMAs are handled by do_anonymous_page() in mm/memory.c: https://lxr.missinglinkelectronics.com/#linux+v4.6/mm/memory.c#L2729 https://lxr.missinglinkelectronics.com/#linux+v4.6/mm/memory... As you can see, a write fault on a not-present page in an anonymous VMA calls alloc_zeroed_user_highpage_movable(), which calls __alloc_zeroed_user_highpage(). The x86 architecture provides an architecture-override for this as a macro which calls alloc_page_vma() with the GFP_ZERO flag added. This calls down through alloc_pages_vma() and __alloc_pages_nodemask() which eventually gets a page through get_page_from_freelist() (potentially via __alloc_pages_slowpath()). get_page_from_freelist() uses prep_new_page() to act on the GFP_ZERO flag ( https://lxr.missinglinkelectronics.com/#linux+v4.6/mm/page_alloc.c#L1519 https://lxr.missinglinkelectronics.com/#linux+v4.6/mm/page_a... ). Unless the (non-default) PAGE_POISONING_ZERO configuration option is set, this clears the page directly with clear_highpage(). The PAGE_POISONING_ZERO option zeroes the page at the time it is freed (so not in the background) - it's intended as a sanitization/hardening option, not a performance one. A read fault on a not-present page in an anonymous VMA maps in the singleton "Zero PTE" which is a read-only PTE pointing at a page of zeroes. A subsequent write fault on this page will end up in wp_page_copy(), which recognises the Zero PTE and calls into alloc_zeroed_user_highpage_movable() instead of copying the page, as before. It would be possible for another architecture to provide a version of __alloc_zeroed_user_highpage() which did use background-zeroing, if it was more efficient on that architecture - I haven't checked to see if any do, though.