[performance problem] CONFIG_DYNAMIC_FTRACE: Increased kernel build times

[performance problem] CONFIG_DYNAMIC_FTRACE: Increased kernel build times

[Ingo Molnar]

Steve,

i did an 64-bit allyesconfig build test (with debug_info disabled), with 
and without CONFIG_DYNAMIC_FTRACE set.

The build time results are:

  -CONFIG_DYNAMIC_FTRACE:   266.30
  +CONFIG_DYNAMIC_FTRACE:   296.07 (+11.2%)

So we get more than 10% build time overhead.

That's quite high - higher than what i remember having measured 
originally when the first iteration of the mcount code went in.

This extra overhead comes from the mcount post-processing script 
(scripts/recordmcount.pl) that runs objcopy as well and is written in 
Perl. I think this whole angle needs to be improved - 10% is way too 
high of a price to pay.

	Ingo

Re: [performance problem] CONFIG_DYNAMIC_FTRACE: Increased kernel build times

[John Kacur]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 879 bytes --]

2009/10/23 Ingo Molnar <mingo@elte.hu> wrote:
> 
> Steve,
> 
> i did an 64-bit allyesconfig build test (with debug_info disabled), with
> and without CONFIG_DYNAMIC_FTRACE set.
> 
> The build time results are:
> 
>  -CONFIG_DYNAMIC_FTRACE:   266.30
>  +CONFIG_DYNAMIC_FTRACE:   296.07 (+11.2%)
> 
> So we get more than 10% build time overhead.
> 
> That's quite high - higher than what i remember having measured
> originally when the first iteration of the mcount code went in.
> 
> This extra overhead comes from the mcount post-processing script
> (scripts/recordmcount.pl) that runs objcopy as well and is written in
> Perl. I think this whole angle needs to be improved - 10% is way too
> high of a price to pay.

Hi Ingo, do you still have the profiling data to share with us?
Was the problem more in objcopy / objdump, rather than in the perl script 
itself?

Thanks

John

Re: [performance problem] CONFIG_DYNAMIC_FTRACE: Increased kernel build times

[Ingo Molnar]

* John Kacur <jkacur@redhat.com> wrote:

> 2009/10/23 Ingo Molnar <mingo@elte.hu> wrote:
> > 
> > Steve,
> > 
> > i did an 64-bit allyesconfig build test (with debug_info disabled), with
> > and without CONFIG_DYNAMIC_FTRACE set.
> > 
> > The build time results are:
> > 
> >  -CONFIG_DYNAMIC_FTRACE:   266.30
> >  +CONFIG_DYNAMIC_FTRACE:   296.07 (+11.2%)
> > 
> > So we get more than 10% build time overhead.
> > 
> > That's quite high - higher than what i remember having measured
> > originally when the first iteration of the mcount code went in.
> > 
> > This extra overhead comes from the mcount post-processing script
> > (scripts/recordmcount.pl) that runs objcopy as well and is written in
> > Perl. I think this whole angle needs to be improved - 10% is way too
> > high of a price to pay.
> 
> Hi Ingo, do you still have the profiling data to share with us? [...]

no finegrained info - i did a perf stat run.

> [...] Was the problem more in objcopy / objdump, rather than in the 
> perl script itself?

in top i saw perl pop up most of the time, that's where i'd suspect a 
good portion of the overhead.

	Ingo

Re: [performance problem] CONFIG_DYNAMIC_FTRACE: Increased kernel build times

[Steven Rostedt]

On Fri, 2009-10-23 at 09:45 +0200, Ingo Molnar wrote:
> Steve,
> 
> i did an 64-bit allyesconfig build test (with debug_info disabled), with 
> and without CONFIG_DYNAMIC_FTRACE set.
> 
> The build time results are:
> 
>   -CONFIG_DYNAMIC_FTRACE:   266.30
>   +CONFIG_DYNAMIC_FTRACE:   296.07 (+11.2%)
> 
> So we get more than 10% build time overhead.
> 
> That's quite high - higher than what i remember having measured 
> originally when the first iteration of the mcount code went in.
> 
> This extra overhead comes from the mcount post-processing script 
> (scripts/recordmcount.pl) that runs objcopy as well and is written in 
> Perl. I think this whole angle needs to be improved - 10% is way too 
> high of a price to pay.

Yeah, I know this is quite a hit, and to fix this is on my todo list.
What I plan on doing is checking if libelf is installed, and if it is,
then doing a C program that does the linking and checking. If not, it
defaults back to the perl code.

But I'm bug hunting right now, and that takes a higher priority.

-- Steve