> There should definitely be a nice API for an in-kernel AltiVec context
> save/restore. When preemption happens doesn't it do some equivalent of
> the userspace context switch? Why can't the preemption system take care
> of it?
>
> At worst case you make the worst case latency bigger, but at bes
Scott Wood wrote:
Benjamin Herrenschmidt wrote:
Yuck.
Hmm? It's simple and achieves the desired result (avoiding
non-preemptible regions without unduly restricting the ability to
extract performance from the hardware).
Would it be nicer to avoid FP/Altivec in the kernel altogether? Sure
Benjamin Herrenschmidt wrote:
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.
Yuck.
Sadashiiv, Halesh writes:
> I have tested the testcase that I have provided at the time of reporting
> this issue. But it didn't work as expected with the above patch you
> provided.
> (Failed to return EINVAL on negative value of n to select())
How is your testcase invoking select? Is it doing
> 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.
Yuck.
Ben.
___
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
On Sun, Oct 12, 2008 at 09:32:07AM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2008-10-08 at 12:40 -0500, Scott Wood wrote:
> >
> > The performance difference most likely comes from the fact that copy
> > to/from user can assume that the memory is cacheable, while memcpy is
> > occasionally u
>>Please don't apply Arnd's patch. As I said, all we need is this
>>one-line change in arch/powerpc/include/asm/systbl.h:
>>
>>-SYSX_SPU(sys_select,ppc32_select,ppc_select)
>>+SYSX_SPU(sys_select,ppc32_select,sys_select)
>
>
>I have tested the testcase that I have provided at the time of
report
>-Original Message-
>From: Paul Mackerras [mailto:[EMAIL PROTECTED]
>Sent: Friday, October 10, 2008 1:14 PM
>To: [EMAIL PROTECTED]
>Cc: Arnd Bergmann; linuxppc-embedded@ozlabs.org; Sadashiiv, Halesh;
>[EMAIL PROTECTED]
>Subject: Re: [PATCH] remove bogus ppc_select syscall
>
>Benjamin Herr
