On Fri, Oct 14, 2011 at 01:01:35AM +0200, Sergio López wrote: > vm_object_copy_delayed(), which is being used when copying from an > object with the MEMORY_OBJECT_COPY_DELAY attribute, is not designed > for doing small, repetitive reads from an object (which is what we're > usually doing with vm_copy). Using it this way is slower than copying > the pages without any optimization (as with MEMORY_OBJECT_COPY_NONE).
I assume you're comparing copies with no further modification to the transferred buffers. In this case, it seems more like another effect of the Mach VM issues. I agree that trying to fix those is tedious, and even dangerous, but the workaround you're suggesting doesn't look appropriate either. The speed of raw and virtual copies is very dependent on both the size of the transfers and the hardware used. We shouldn't change that behaviour until at least solid measurements are available. Even if doing so, it's still a hack. I agree however that the access type should be considered. In order to avoid changing the existing interface, a new call, say vm_copy_raw(), could be added and unconditionnally use the COPY_NONE strategy, for applications which know they'll modify the received buffer, or frequently transfer small amounts of data. The same could be done for vm_read/vm_write of course. -- Richard Braun
