[lkml]   [2008]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: frame unwinder patches
On Fri, 5 Sep 2008 16:48:52 +0200
Bernd Schubert <> wrote:

> On Friday 05 September 2008 16:13:37 Arjan van de Ven wrote:
> > On Fri, 5 Sep 2008 15:52:47 +0200
> >
> > Bernd Schubert <> wrote:
> > > > (and if you really care it's 1 line of code to turn it off)
> > >
> > > It is not only this, I think the dwarf2 stack unwinder patches
> > > provide by far better traces than the in-kernel unwinder. At least
> > > ever since I applied these patches to our kernels, I was able to
> > > read the stack dumps...
> >
> > they really wouldn't be different than the ones you get if you
> > remove the "?" lines.
> Well may be, but then there is still the performace degrading, so I
> don't want to have it enabled on our production kernels. I admit I
> never measured what is the difference between of
> CONFIG_FRAME_POINTER=y and =n, but the fact the help text says there
> is a difference already makes me want to disable it (especially,
> since we have to provide benchmarks before we can sell a system).

to be honest, on 64 bit the overhead is quite small (the extra
instructions it adds are optimized for by the modern cpus that you use
in the systems you're selling); on 32 bit the overhead is.. well a
little bigger but not THAT much. yes it loses a register for the
compiler to use, but no it's not a general purpose register, and with
the register renaming that today's cpus do, I'd be surprised if you
could see anything significant.

If you want to reach me at my work email, use
For development, discussion and tips for power savings,

 \ /
  Last update: 2008-09-05 16:59    [W:0.033 / U:2.572 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site