Re: [PATCH 0/2] More i387 state save/restore work

[Benjamin Herrenschmidt]

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.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/