Messages in this thread |  | | | Date | Tue, 9 Mar 2010 17:59:57 +1100 | | From | Nick Piggin <> | | Subject | Re: [PATCH -tip] introduce sys_membarrier(): process-wide memory barrier (v9) |
| |
On Sat, Mar 06, 2010 at 11:43:26AM -0800, Linus Torvalds wrote: > > > On Thu, 4 Mar 2010, Ingo Molnar wrote: > > > > Perhaps NOFPU could do lazy context saving: clear the TS flag and only save > > the FPU state if it's actually used by the signal handler? > > If we can get that working reliably, we probably shouldn't use NOFPU at > all, and we should just do it unconditionally. That big (and almost always > pointless) FPU state save is a _big_ performance issue on signal handling, > and if we can do it lazily, we should. > > However, I'm not at all convinced we can do this reliably. How do we > detect the "signal frame is dead" case with things like siglongjmp() etc? > > And if we can't detect that "frame no longer exists", we can't really do > the lazy context saving. > > Now, there's _also_ the issue of the signal handler function possibly > actually looking at the FPU state on the stack, and for that, a SA_NOFPU > would be a good way to say "you can't do that". So it's possible that even > if we could reliably detect the frame liveness we'd really have to use > that new flag anyway. > > But if we do need a SA_NOFPU flag, then that means that basically no app > will use it, and it will be some special case for some really unusual > library. So I really don't think this whole thing is worth it unless you > could do it automatically.
The library is librcu, which I suspect will become quite important for parallel programming in future (maybe I hope for too much).
But maybe it's better to not merge _any_ librcu special case until we see results from programs using it. More general speedups or features (that also help librcu) is a different story.
|  |