lkml.org 
[lkml]   [2012]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 0/2] More i387 state save/restore work
From
Date
On Sun, 2012-02-19 at 17:11 -0800, Linus Torvalds wrote:
> Oh, and final comment - looking at the thing you pointed at, it looks
> much more adventurous than my x86 FP state thing.

Right, that's the main reason why I haven't merged it (yet...). I though
the added complexity and risk wasn't worth the added complexity and
risk.

But going half way there as you are doing definitely looks like a good
idea. I'll have a look when I'm done whacking the shit out of our
exception entry path :)

> I always save things unconditionally, so that I don't have to do the
> IPI or just in general care about the "oops, now I want things in
> memory, not in some random CPU FP state". So mine is just a "writeback
> cache", and only optimizes the reading things back: there is never any
> dirty state in the CPU except when the process is actively using it.
>
> That obviously does mean that I only optimize away the restore side,
> not the save side. But it's *way* simpler, and considering that I just
> spent almost a week trying to figure out FP state save bugs, simple is
> good.

On the other hand, you seem to support FP use from random kernel
contexts such as softirq, interrupts etc... while we don't (well not
with the "normal" APIs, obviously you can always turn all IRQs off and
manually enable & save restore but that's too nasty for words).

Cheers,
Ben.




\
 
 \ /
  Last update: 2012-03-01 12:33    [W:0.058 / U:4.568 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site