Re: performance: memcpy vs. __copy_tofrom_user

[Matt Sealey <matt@genesi-usa.com>]

Scott Wood wrote:
> BTW, it's actually simpler than I originally described (I had implemented
> this years ago in the TimeSys kernel for x86 and some other arches that
> already use FP or similar resources for memcpy, but the memory was a
> little fuzzy); the FP restore code doesn't need to test anything, it
> always restores from the regular spot.  The kernel code wishing to use FP
> saves the user context in an alternate save area (it could even be on the
> stack, allowing atomic context to use it as well, if it's not too large),
> and restores it when it's done.

Sure, it's simple, the problem is that VRSAVE isn't maintained in the 
kernel, which means for AltiVec context switches you need to save and 
restore 32 128-bit registers every time. And that takes a LONG time..

Just imagine if you did a ~512 byte memcpy, you could guarantee that it 
would take twice as long as it should!

There are ways around it, like assembly and fixed registers, and saving 
the ones you use (this is the sort of thing gcc does for you usually, 
but you can do it by hand just as well) and restoring the ones you 
trashed afterwards, but that makes code messier and less readable.

Not insurmountable problems, but it makes using AltiVec harder. You
would have to really justify a speed increase. I think you could get
that on cryptography functions easily. For page zero/copying, I think 
you would also get the increase to outweigh the prologue/epilogue 
required and also the loss of preemption.

TCP/IP copy with checksum? Probably absolutely definitely..

Straight memcpy? I am not so sure.

Like I said I am far more worried about how you'd get a reasonable
benchmark out of it. Profiling kernels is a messy business..

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations