Re: Kernel oops with 2.6.26, padlock and ipsec: probably problem with fpu state changes

[Suresh Siddha <suresh.b.siddha@intel.com>]

On Tue, Aug 12, 2008 at 05:02:13AM -0700, Herbert Xu wrote:
> On Tue, Aug 12, 2008 at 01:43:22PM +0200, Wolfgang Walter wrote:
> >
> > * Works fine, machine is up since 61 minutes.
> 
> Thanks a lot for testing this Wolfgang!

Thanks indeed.

> > * Performance:
> >
> > Routing performance over esp-tunnels seems unchanged here compared to 2.6.25
> > (this was also the case with the "kernel_fpu_begin" patch).
> >
> > tcrypt mode=200 shows exactly the same performance penalty compared to 2.6.25
> > as the "kernel_fpu_begin" patch.
> 
> That's not surprising since tcrypt runs with BH off so it'll
> do pretty much the same thing as before.

Ok. In the real world usage, where we use these instructions both from
process and softirq context, we will probably not see much penality,
as the process context's first access will always endup doing full fp restore
(and also we kick in the context switch FP optimization, which will
proactively restore fp state if we touch FPU in 5 consecutive task slices).

> This also shows that
> reading CR0 doesn't impose any extra overhead compared to what
> was done in kernel_fpu_begin.

As there are no further objections, Herbert/Ingo not sure who among you
will push this patch to Linus tree and  2.6.26 -stable tree aswell.

thanks,
suresh