Dragonfly actually removed it two years ago: http://lists.dragonflybsd.org/pipermail/commits/2016-August/...

  - Pre-zeroing a page only takes 80ns on a modern cpu.  vm_fault overhead
    in general is ~at least 1 microscond.
  - Pre-zeroing a page leads to a cold-cache case on-use, forcing the fault
    source (e.g. a userland program) to actually get the data from main
    memory in its likely immediate use of the faulted page, reducing
    performance.
  - Zeroing the page at fault-time is actually more optimal because it does
    not require any reading of dynamic ram and leaves the cache hot.
  - Multiple synth and build tests show that active idle-time zeroing of
    pages actually reduces performance somewhat and incidental allocations
    of already-zerod pages (from page-table tear-downs) do not affect
    performance in any meaningful way.

or physically pull the RAM out, keeping it cold with LN2, and stick it into devices designed for reading it all out.

The starting point is that there is stale, useless data in ram. Then a usermode program requests an empty page, and usually when they do this they want to immediately use it.(1) Using non-polluting writes, you have to use main memory bandwidth both for clearing the page, and also for bringing the page back to cache immediately afterwards when the program uses it.

Using writes that just allocate new, cleared dirty lines in cache (like the AMD CLZERO), it avoids both the write (which will happen later, when the lines are evicted from cache, probably after the lines have been used by the program), and the read because the lines are now all in the cache.

(1) And on Linux this is trivially true, because Linux only allocates and clears the page when it is first accessed.

Your system: memory is released, kernel clears it in the background, wasting write bandwidth (which might not matter for anything except power if the system was idle at the time), and when the user-mode program starts using it, it will start writing and every new line they write to will trigger a spurious read.

Modern Linux: memory is released, kernel lets it lie, not using any power or bandwidth to do anything to it, until an user-mode program allocates it and touches the page. Then the kernel picks up the page, writes the entire page with 0:es using whatever idiom on that CPU allows it to just allocate the page in cache without reading it from the RAM. This is really fast, faster than a single memory fetch. The user-mode program can then directly use it without having to fetch anything from DRAM.

Nit: it's faster than a page fault (so fault + zeroing is pretty much the same as just fault).

According to the recent-ish Latency Numbers, a main memory reference is ~100ns (variable by arch and local v remote DRAM) which is about the same as zeroing a page, at least with respect to the dragonfly numbers I posted above.

Any idea why that's necessary ? So it's preempted by a IDLE process.

Also, do not conflate the user-thread idle priority class with the (non-)priorities of Idle Threads.

The idle task (when there's nothing to run) doesn't have a priority at all, it just gets run when nothing else is available. the "idle" priority is an actual priority, for when there's no higher-priority task to run. The ZPT is prioritized below "idle", so super-duper-low priority.