[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091119184716.GA25458@elte.hu>
Date: Thu, 19 Nov 2009 19:47:16 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Richard Guenther <richard.guenther@...il.com>, rostedt@...dmis.org,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>,
LKML <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Heiko Carstens <heiko.carstens@...ibm.com>,
feng.tang@...el.com, Fr??d??ric Weisbecker <fweisbec@...il.com>,
Peter Zijlstra <peterz@...radead.org>, jakub@...hat.com,
gcc@....gnu.org
Subject: Re: BUG: GCC-4.4.x changes the function frame on some functions
* Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> Admittedly, anybody who compiles with -pg probably doesn't care deeply
> about smaller and more efficient code, since the mcount call overhead
> tends to make the thing moot anyway, but it really looks like a
> win-win situation to just fix the mcount call sequence regardless.
Just a sidenote: due to dyn-ftrace, which patches out all mcounts during
bootup to be NOPs (and opt-in patches them in again if someone runs the
function tracer), the cost is not as large as one would have it with say
-pg based user-space profiling.
It's not completely zero-cost as the pure NOPs balloon the i$ footprint
a bit and GCC generates different code too in some cases. But it's
certainly good enough that it's generally pretty hard to prove overhead
via micro or macro benchmarks that the patched out mcounts call sites
are there.
Ingo
--
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/
Powered by blists - more mailing lists