>If you want to investigate this, you really need to measure the result
>on real workloads.
>
>My gut feel here is that you'll discover that, in practice, most ZFOD
>pages are written shortly after they are touched for the first time,
>and this "optimization" would save very little memory and consume lots
>of extra cpu; 

Measurements taken with the V-kernel on 1990s workstations
(decstation 5000/200) showed it was a net win there.  (The real-ness
of those workloads is open to question; at one point it included
running Ultrix X11R5 desktop and apps under Unix emulation).

The gut feel at the time was that processes ended up *referencing*
large BSS objects, but not writing to all of the pages in the objects.
Enough so that sharing a readonly zero page for initial references was
a net win.  I'm with Bill here: measure, measure, measure.

Kieran Harty's PhD thesis may have details.  Brian Bershad's work on
CML buffers might have relevant data, too.

>the "COW" fault would also require a TLB shootdown on
>multiprocessor systems whereas touching an previously unmapped page
>does not require TLB invalidation (since there can't be a previous
>live TLB entry).

All good points.  So perhaps if this is still a win for uniprocessors,
it should be enabled there; but not on multiprocessors (if at all).