At 05:35 AM 5/08/2002 +0000, Linus Torvalds wrote:
> >Linux got a lot slower in signal delivery when the SSE2 support was
> >added. That got this speed back.
>
>This will break _horribly_ when (if) glibc starts using SSE2 for things
>like memcpy() etc.
>
>I agree that it is really sad that we have to save/restore FP on
>signals, but I think it's unavoidable. Your hack may work for you, but
>it just gets really dangerous in general. having signals randomly
>subtly corrupt some SSE2 state just because the signal handler uses
>something like memcpy (without even realizing that that could lead to
>trouble) is bad, bad, bad.
how about putting the onus on userspace to tell the kernel if/when it uses
extensions that require FP state to be saved/restored?
if/when glibc starts using SSE2, it could then use these extensions.
could be as simple as user-space setting some bit somewhere.
>And yes, this signal handler thing is clearly visible on benchmarks.
>MUCH too clearly visible. I just didn't see any safe alternatives
>(and I still don't ;( )
it probably isn't worthwhile penalising all users of signal just for those
few userspace apps that actually do use SSE2.
cheers,
lincoln.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Aug 07 2002 - 22:00:26 EST