Re: [PATCH -tip] introduce sys_membarrier(): process-wide memorybarrier (v9)

[Nick Piggin]

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.

--
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/