![]() | |||||||||||||
Messages in this thread |
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/ | ||||||||||||
| Last update: 2005-03-22 12:27 [from the cache] ©2003-2008 | |||||||||||||