performance: memcpy vs. __copy_tofrom_user

Scott Wood scottwood at
Tue Oct 14 02:20:28 EST 2008

On Sat, Oct 11, 2008 at 09:05:49PM -0500, Matt Sealey wrote:
> Benjamin Herrenschmidt wrote:
> >The reason where we require a -real-good- reason to do it is
> >simply because of the drawbacks. The cost of enabling altivec
> >in the kernel can be high (especially if the user is using it)
> >and it's not context switched for kernel code (just like the
> >FPU) for obvious performance reasons. Thus any use of altivec in the
> >kernel must be done within non-preemptible sections, which can
> >cause higher latencies in preemptible kernels.

It doesn't need to be done in non-preemptible sections, if you have a
separate per-thread save area for kernel fp/altivec use (and appropriate
flags so an FP unavailable handler knows which regs to restore), and you
can avoid using it in a preempting context.

In a realtime-configured kernel, preempting contexts should be fairly
minimal, so the loss of altivec use is not of critical performance impact
(other than one branch to determine if it can be used).

In a throughput-configured kernel, do it as you described (disable
preemption), and be able to use altivec memcpy in interrupt handlers, and
reduce the thread size.

> Would the examples (page copy, page clear) be an okay place to do it?
> These sections can't be preempted anyway (right?),

Why can't they be preempted?


More information about the Linuxppc-embedded mailing list