Messages in this thread | | | Date | Mon, 11 Aug 2008 13:19:01 -0700 | From | Suresh Siddha <> | Subject | Re: Kernel oops with 2.6.26, padlock and ipsec: probably problem with fpu state changes |
| |
On Mon, Aug 11, 2008 at 12:24:59PM -0700, H. Peter Anvin wrote: > Ingo Molnar wrote: > > * Suresh Siddha <suresh.b.siddha@intel.com> wrote: > > > >> Reported-and-bisected-by: Wolfgang Walter <wolfgang.walter@stwm.de> > >> Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> > > > > no fundamental objection to the x86 bits. > > > > shouldnt this: > > > > + if (!in_interrupt()) > > + return 0; > > > > just be eliminated and the cr0/TS save/restore be made unconditional? > > irq-assymetric APIs are not nice in general. > > > > Reading/setting cr0 isnt _that_ slow. (or if it is, by how much does it > > slow things down, exactly?) > > > > Setting it is relatively slow. I think that's part of the reason for > special instructions to muck with the TS flag. > > Reading it might be slow on obsolete processors.
In addition to the slowness(Wolf has collected some data with earlier patch and I think it showed a double digit increase in cpu utilization with some crypt tests):
we can't unconditionally do clts() in the process context. We have to disable pre-emption to avoid interactions with context switch and lazy restore. So there will be RT latency issues aswell.
thanks, suresh
| |