From: Steven Rostedt <rostedt@goodmis.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
linux-arch@vger.kernel.org, Michal Marek <mmarek@suse.cz>,
linux-kbuild@vger.kernel.org, John Reiser <jreiser@bitwagon.com>
Subject: Re: [PATCH 2/3] ftrace/x86: Add support for C version of recordmcount
Date: Thu, 14 Oct 2010 23:14:09 -0400 [thread overview]
Message-ID: <1287112449.23682.27.camel@gandalf.stny.rr.com> (raw)
In-Reply-To: <20101015025047.GA9640@elte.hu>
On Fri, 2010-10-15 at 04:50 +0200, Ingo Molnar wrote:
> * Steven Rostedt <rostedt@goodmis.org> wrote:
>
> > From: Steven Rostedt <srostedt@redhat.com>
> >
> > This patch adds the support for the C version of recordmcount and
> > compile times show ~ 12% improvement.
>
> I reported this recordmcount performance problem 2 years ago. Better
> later than never i guess.
And I also remember saying after I posted this code that it would have a
compile time performance hit. Heck, it's a perl script running on every
object file. It was obvious what was at issue here. But it's better to
slow down the kernel build than to brick network cards. Also, perl was
much easier to do.
That said, the embarrassing thing is not that I knew (or you reported
it) about this performance problem. I'm actually quite embarrassed that
I had this code sitting in my inbox for over a year. I just kept having
other things that were more important coming up than lowering the
compile time of the kernel. Although, I did work to get streamline
config to offset this performance hit.
Finally, while at the End Users Summit, I decided to take a look at
John's code, and I was quite impressed.
But as you said, better late than never.
>
> > +ifdef CONFIG_DYNAMIC_FTRACE
> > + ifdef CONFIG_HAVE_C_MCOUNT_RECORD
> > + BUILD_C_RECORDMCOUNT := y
> > + export BUILD_C_RECORDMCOUNT
>
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -33,6 +33,7 @@ config X86
> > select HAVE_KRETPROBES
> > select HAVE_OPTPROBES
> > select HAVE_FTRACE_MCOUNT_RECORD
> > + select HAVE_C_MCOUNT_RECORD
>
> The naming is inconsistent here - it should be HAVE_C_RECORDMCOUNT, like
> the build variable has, and like the utility is called. If we are going
> to add this flag to most architectures we should name it consistently.
Sure, want me to rebase it or just write a patch on top of it?
-- Steve
next prev parent reply other threads:[~2010-10-15 3:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20101014210014.895157788@goodmis.org>
2010-10-14 21:00 ` [PATCH 2/3] ftrace/x86: Add support for C version of recordmcount Steven Rostedt
2010-10-14 21:00 ` Steven Rostedt
2010-10-15 2:50 ` Ingo Molnar
2010-10-15 2:50 ` Ingo Molnar
2010-10-15 3:14 ` Steven Rostedt [this message]
2010-10-15 3:14 ` Steven Rostedt
2010-10-15 3:18 ` Ingo Molnar
2010-10-15 3:18 ` Ingo Molnar
2010-10-15 3:23 ` Steven Rostedt
2010-10-27 3:25 ` Paul Mundt
2010-10-27 3:25 ` Paul Mundt
2010-10-29 2:34 ` John Reiser
2010-10-29 2:34 ` John Reiser
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=1287112449.23682.27.camel@gandalf.stny.rr.com \
--to=rostedt@goodmis.org \
--cc=akpm@linux-foundation.org \
--cc=fweisbec@gmail.com \
--cc=jreiser@bitwagon.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mmarek@suse.cz \
/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;
as well as URLs for NNTP newsgroup(s).