In D7714#160303, @imp wrote:

seems reasonable to me (in that it does what it says it does), but what's the motivation?

The motivation was to make it a bit easier to create fast paths in the page allocator. Right now, vm_page_zero_count and vm_page_zero_idle_wakeup() are protected by the heavily-contended free page queue mutex. I'd like to be able to free a page to a superpage reservation without having to acquire this lock, for example.

Moreover, the feature seems quite broken: on multicore amd64 systems, the idle-priority pagezero thread induces a priority inversion by holding the free page lock while other higher-priority threads spin on it. Kostik also pointed out that vm_pagezero() yields the CPU while holding the free page lock in !PREEMPTION kernels, which seems incorrect. Further, I note that we potentially wake up pagezero after freeing a page to a reservation, but such pages do not belong to the physical memory allocator and are thus not visible to pagezero in vm_phys_zero_pages_idle(). Given that this feature has been disabled by default since r170816, I think it's reasonable to remove it.

Thanks @markj for elaborate explanation; please include at least an excerpt of it in the commit log.