COPY_DELAY could perform worse than COPY_NONE

[Sergio López]

Hi,

While compiling stuff to stress my test machine, I've noticed ext2fs
was eating a lot of CPU time, specially when running ranlib or
objcopy. Further investigations showed that most of this time was
expended in this fragment of vm_object.c:vm_object_copy_delayed:

---
        queue_iterate(&src_object->memq, p, vm_page_t, listq) {
            if (!p->fictitious)
                pmap_page_protect(p->phys_addr,
                                  (VM_PROT_ALL & ~VM_PROT_WRITE &
                                   ~p->page_lock));
        }
---

In objects where copy attribute is MEMORY_OBJECT_COPY_DELAY, for every
read operation (usually done with vm_copy) all pages in the source
object are write protected to be able to use copy-on-write
optimizations. The cost for this operation seems to be higher than
actually copying the pages for objects larger than just a bunch of
pages. Moreover, this CoW optimization is lost for requests larger
than 2k, since MiG stubs copy (with a conventional memcpy) the data
from the buffer received in the message, to the actual address
expected by the client.

I did a quick test changing ext2fs to use MEMORY_OBJECT_COPY_NONE, and
this reduced the compilation time for webkitgtk+ from ~11h40m to
~7h5m.