bug-hurd
[Top][All Lists]
Advanced

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

Re: memory_object_lock_request and memory_object_data_return fnord


From: Roland McGrath
Subject: Re: memory_object_lock_request and memory_object_data_return fnord
Date: Sun, 24 Mar 2002 18:14:22 -0500 (EST)

I am pretty dubious about modifying memcpy at this point.  There are a lot
of different implementations in libc, and they are being further tweaked
all the time.  There are both assembly implementations and inline-macro
implementations, and many of each for all the tiny variants of chip that
exist for each platform and are worth optimizing to differently.  Then
there's the compiler, which is free to inline it however it likes (and gcc
3.x does often, I gather).  I am guessing that the cases that would be
covering multipage ranges are ones that don't get inlined--but the compiler
would be perfectly in its rights to partially inline them and insert calls
to its own support functions in libgcc or whatever.  I think it will be an
unrewarding uphill battle to put the onus on the libc and gcc maintainers
to make sure that the page-copy hooks are always used in applicable cases.

It costs very little the have an explicit check in pager_memcpy.  In fact,
in the all-whole-pages case checking up front can save the overhead of
arranging to handle a possible fault in memcpy.

OTOH, it occurred to me that on the x86 it would be pretty easy to make a
special case in the user page fault handling to recognize a standard memcpy
going on (that is, "rep; movsl") and simulate the instruction's action over
a range of whole pages with vm_copy rather than servicing the fault
normally.  Muwhahaha.  This doesn't avoid copying pages that are already in
core (and the destination page writable), but I wonder what the actual
speed of copying N*4k with movsl vs doing the system call and VM twiddling
is (copying hundreds of MB already in core to hundreds of MB already in
core could be much slower, I suppose)--though of course the virtual copy
also knows it's a virtual copy and so maybe avoids duplicate copies or
pageouts later on, and so forth.  And it doesn't help the i486 and i586
optimized mempcy versions, which don't use the string instructions.
But I just had to share the gruesome idea.




reply via email to

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