mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®