[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.1.10.0808082202030.4894@gandalf.stny.rr.com>
Date: Fri, 8 Aug 2008 22:03:42 -0400 (EDT)
From: Steven Rostedt <rostedt@...dmis.org>
To: Andi Kleen <andi@...stfloor.org>
cc: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
David Miller <davem@...emloft.net>,
Roland McGrath <roland@...hat.com>,
Ulrich Drepper <drepper@...hat.com>,
Rusty Russell <rusty@...tcorp.com.au>,
Jeremy Fitzhardinge <jeremy@...p.org>,
Gregory Haskins <ghaskins@...ell.com>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
"Luis Claudio R. Goncalves" <lclaudio@...g.org>,
Clark Williams <williams@...hat.com>
Subject: Re: [PATCH 0/5] ftrace: to kill a daemon
On Sat, 9 Aug 2008, Andi Kleen wrote:
> > Funny, CONFIG_FTRACE happens to select that. Now the question is, would
> > mcount work without it?
>
> Not without fixing gcc first. It would work if gcc always called
> mcount the first thing before setting up the stack frame. Not
> sure why it doesn't do that.
I could take out the frame pointer option and pass in zero for the parent
in such that case. But the parent is quite useful. But if it helps
with performance, it may be worth doing this.
-- Steve
>
> Still do a benchmark of frame pointer vs no frame pointer kernel
> and you'll see, especially on a older CPUs without special hardware
> to avoid stack stalls (e.g. not Core2)
I'll see what it does with just a kernel build.
-- 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/
Powered by blists - more mailing lists