From: rostedt@goodmis.org (Steven Rostedt)
To: linux-arm-kernel@lists.infradead.org
Subject: ftrace performance impact with different configuration
Date: Fri, 30 Dec 2011 17:25:41 -0500 [thread overview]
Message-ID: <1325283941.24045.15.camel@gandalf.stny.rr.com> (raw)
In-Reply-To: <23257775.9kkYY4quUh@laptop>
On Fri, 2011-12-30 at 14:07 +0100, Philippe R?tornaz wrote:
> Sorry about being a bit naive, but why it is not possible to do it in two
> steps ?
> call stop_machine to put the jmp which skip the call to mcount
> Then wait until all tasks hits schedule() (synchronize_sched() ?)
Here's the problem. With a preemptible kernel, hitting schedule() does
not mean that you can guarantee that all tasks have not been
interrupted.
nop (use to be push lr)
------------> interrupt
set NEED_RESCHED
end of interrupt
preempt_schedule()
schedule()
[ another processes is now running ]
call stop_machine()
put in push lr
call stop_machine()
put in call to mcount
everything seems to be running fine.
the low priority task gets scheduled again...
schedule() finishes
preempt_schedule() finishes
back at tail of return_from_intr in entry_64.S
iret
call mcount
pop lr (which was never pushed)
jmp lr
Now we jump back to some random stuff and the stack is corrupted.
There's no way to safely modify two instructions that depend on each
other in a preemptible kernel, with the exception of waiting for all
CPUs to hit idle (which may never happen on a busy system). And even
that may be racy.
-- Steve
> Then modify both instructions to put in place the two nops since we know that
> nobody is calling mcount.
next prev parent reply other threads:[~2011-12-30 22:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-29 8:38 ftrace performance impact with different configuration Lei Wen
2011-12-29 15:42 ` Rabin Vincent
2011-12-29 16:21 ` Steven Rostedt
2011-12-30 13:07 ` Philippe Rétornaz
2011-12-30 22:25 ` Steven Rostedt [this message]
2011-12-30 23:31 ` Philippe Rétornaz
2012-01-04 10:06 ` Lei Wen
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=1325283941.24045.15.camel@gandalf.stny.rr.com \
--to=rostedt@goodmis.org \
--cc=linux-arm-kernel@lists.infradead.org \
/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