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. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
