Which of course can't be used at all on SMP boxes; and I even have
doubts about its performance on a UP box when you've got more than
one task going. strcpy() is not an uncommon routine, if all the
processes on a box were using the FPU to do strcpy() it probably
won't be a pretty thing -- every context switch would require FPU
switching as well.
For some things on some architectures, the performance gain from FPU
based memcpy/csum_copy/etc. are so large that we even do it in the
kernel on sparc64.
The trick is to have a heuristic which decides whether the cost of
(possible) extra FPU saves/restores overcomes the gain in performance
from the FPU version of the code. This heuristic is available always
for the memcpy/csum_copy cases, but it isn't (and would almost never
be met in any event) for the str{n}cpy() cases.
Later,
David S. Miller
davem@dm.cobaltmicro.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu