linux-kernel - Re: [PATCH 2/3] ftrace/x86: Add support for C version of recordmcount

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]

Message-ID: <1287112449.23682.27.camel@gandalf.stny.rr.com>
Date:	Thu, 14 Oct 2010 23:14:09 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	linux-arch@...r.kernel.org, Michal Marek <mmarek@...e.cz>,
	linux-kbuild@...r.kernel.org, John Reiser <jreiser@...wagon.com>
Subject: Re: [PATCH 2/3] ftrace/x86: Add support for C version of
 recordmcount

On Fri, 2010-10-15 at 04:50 +0200, Ingo Molnar wrote:
> * Steven Rostedt <rostedt@...dmis.org> wrote:
> 
> > From: Steven Rostedt <srostedt@...hat.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

--
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/