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 <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Reply via email to