Re: COPY_DELAY could perform worse than COPY_NONE

[Richard Braun]

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