Zero Filling - Part VI - A Readers Suggestion

I got an email from Maynard Handley with a good suggestion:
There is another way to look at your zero page-filling issue, and one you might try to get Apple to adopt. Rather than zero-ing a page on demand (as is done currently) the kernel maintains a list of pre-zeroed pages. This list is refreshed by some kernel-thread that's running every so often, and that takes the pages it want's to pre-zero from say the free-list (or a new free-but-dirty) list. Now the work still has to be done, but with luck it'll be done during some dead time while we're waiting on a disk IO or whatever.

Maynard

A good suggestion and a suggestion that would work. I had asked the same thing Jim Magee off list:
In the back of my mind lurks that factoid, that Mac OS X has a queue of zeroed RAM pages. If the queue is full, then probably a page fault can be serviced in 4-5 us. When it becomes exhausted, like my test program will do it will take 15 us. Correct ? How big is that queue ? And at what rate does it refill ?

The answer was:
Nope. Nothing is done ahead in this regard. Other Mach implementations experimented with this (having the idle loop zero pages ahead instead of doing "nothing"). But it tended to play hell with caches and/or power-management (we _really_ put the processor to sleep in idle).

I would suspect the cache is more of an issue, since the system oughta quiet down after enough pages have been zeroed. Since cleaning a page does invalidate a sizeable part of the cache, this would be quite detrimental to running code I would think.
If I get a little more idle time, I might wrap this up and make Parts I to VI a bona fide "Mulle" article. :)