| just reading the UVM dissitation and I noted the following remark om page 
| 11 :
|
| ``This (backing object for a page) is usually a file or `zero-fill' memory
| wich means that the area should be filled with zeroed memeory as its
| accessed. (....) For zero-fill memory, the copy-on-write flag doesn't
| matter''
|
| I disagree with this ... why shouldn't zero filled memory be backed with
| just *one* by all processes shared R/O page when it faults for reading that
| uses copy-on-write to get a private one if something changed ?
|
| Is this allready done in UVM ? or is it explained later on ? seems spilling
| pages otherwise.... if a process would only just _READ_ that memory it
| would get heaps of zeroed memory pages ... where it could be just one zero 
| page it reads over and over again ... writing one of the pages then gives a 
| new fresh page for its modifications.

So instead of allocating and zeroing a new page on a read fault you do it on a
write fault?  I don't really see this as such a huge optimization.  

Let's examine:

With the current scheme, when you access a ZFOD page either for reading or
writing you take a fault, a page is allocated and zeroed and mapped in as
modified.  You take no more faults on the page until some other operation 
changes it's attributes.

If we have a single zero page and do COW you will usually take two faults:
first you take one to map in the zero page on the first read, then when the
first write occurs you take a more expensive fault to remove the old mapping
and allocate a new ZFOD page.  The COW path needs to be made more complicated
to recognize the special COW of page zero so you can allocate from the zero'ed
page list or use pmap_clear_page() instead of pmap_copy_page() (which is twice
as expensive).

What do we gain from making this change?  We don't need to allocate swap
immediately when we first read from a ZFOD page.  However, we must still
reserve swap for it in case we do write to the page.  How often do you read 
from a ZFOD page without writing to it immediately afterwards?

I expect that change is probably not an over all optimization.  However,
you can try to gather useage statistics and prove me wrong.

Eduardo