linux-kernel - Re: [PATCH -tip] introduce sys_membarrier(): process-wide memory barrier (v9)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 9 Mar 2010 17:59:57 +1100
From:	Nick Piggin <npiggin@...e.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Nicholas Miell <nmiell@...cast.net>, laijs@...fujitsu.com,
	dipankar@...ibm.com, akpm@...ux-foundation.org,
	josh@...htriplett.org, dvhltc@...ibm.com, niv@...ibm.com,
	tglx@...utronix.de, peterz@...radead.org, Valdis.Kletnieks@...edu,
	dhowells@...hat.com, linux-kernel@...r.kernel.org,
	Chris Friesen <cfriesen@...tel.com>,
	Fr??d??ric Weisbecker <fweisbec@...il.com>
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.

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