[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

COPY_DELAY could perform worse than COPY_NONE

From: Sergio López
Subject: COPY_DELAY could perform worse than COPY_NONE
Date: Tue, 4 Oct 2011 09:54:55 +0200


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)
                                  (VM_PROT_ALL & ~VM_PROT_WRITE &

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]