From: Linus Torvalds <torvalds@linux-foundation.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Steven Rostedt <rostedt@goodmis.org>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Nicholas Miell <nmiell@comcast.net>,
laijs@cn.fujitsu.com, dipankar@in.ibm.com,
akpm@linux-foundation.org, josh@joshtriplett.org,
dvhltc@us.ibm.com, niv@us.ibm.com, tglx@linutronix.de,
peterz@infradead.org, Valdis.Kletnieks@vt.edu,
dhowells@redhat.com, linux-kernel@vger.kernel.org,
Nick Piggin <npiggin@suse.de>,
Chris Friesen <cfriesen@nortel.com>,
Fr??d??ric Weisbecker <fweisbec@gmail.com>
Subject: Re: [PATCH -tip] introduce sys_membarrier(): process-wide memory barrier (v9)
Date: Sat, 6 Mar 2010 11:43:26 -0800 (PST) [thread overview]
Message-ID: <alpine.LFD.2.00.1003061135160.31447@localhost.localdomain> (raw)
In-Reply-To: <20100304202304.GA13718@elte.hu>
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 "user accesses the frame" case _could_ possibly be handled by
pointing the FP frame to a special faulting location, and never nesting
the FP optimization. Nested signal handlers are unusual enough that they
aren't worth optimizing for anyway. So I'm sure that there are possible
solutions for "automatically just do the right thing" in theory, but I
suspect they get rather complex)
Linus
next prev parent reply other threads:[~2010-03-06 19:45 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-25 23:23 Mathieu Desnoyers
2010-03-01 14:25 ` Mathieu Desnoyers
2010-03-02 17:52 ` Josh Triplett
2010-03-02 23:07 ` Mathieu Desnoyers
2010-03-03 1:53 ` Josh Triplett
2010-03-04 12:23 ` Ingo Molnar
2010-03-04 15:52 ` Mathieu Desnoyers
2010-03-04 16:03 ` Mathieu Desnoyers
2010-03-04 16:34 ` Linus Torvalds
2010-03-04 16:50 ` Paul E. McKenney
2010-03-04 17:56 ` Mathieu Desnoyers
2010-03-15 20:53 ` Mathieu Desnoyers
2010-03-16 7:36 ` Ingo Molnar
2010-03-16 7:57 ` Nick Piggin
2010-03-16 13:05 ` Mathieu Desnoyers
2010-03-16 13:13 ` Ingo Molnar
2010-03-16 13:35 ` Mathieu Desnoyers
2010-03-16 13:56 ` Ingo Molnar
2010-03-16 14:16 ` Mathieu Desnoyers
2010-03-04 20:23 ` Ingo Molnar
2010-03-06 19:43 ` Linus Torvalds [this message]
2010-03-09 6:59 ` Nick Piggin
2010-03-10 4:16 ` Mathieu Desnoyers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.2.00.1003061135160.31447@localhost.localdomain \
--to=torvalds@linux-foundation.org \
--cc=Valdis.Kletnieks@vt.edu \
--cc=akpm@linux-foundation.org \
--cc=cfriesen@nortel.com \
--cc=dhowells@redhat.com \
--cc=dipankar@in.ibm.com \
--cc=dvhltc@us.ibm.com \
--cc=fweisbec@gmail.com \
--cc=josh@joshtriplett.org \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@elte.hu \
--cc=niv@us.ibm.com \
--cc=nmiell@comcast.net \
--cc=npiggin@suse.de \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®