CHROMIUM: Enable CONFIG_FUNCTION_TRACER

CHROMIUM: Enable CONFIG_FUNCTION_TRACER

Since it can be used to do nifty tracing of startup times

According to the Kconfig help text, it should have no measurable performance impact as long as it's not runtime enabled (boot time default is disabled).

Signed-off-by: Olof Johansson <olofj@chromium.org>;

[jrbarnette, 2010-05-17 18:28:39]

LGTM

[Olof Johansson, 2010-05-19 00:05:32]

PTAL, had to rebase due to other patches having been merged already.

[jrbarnette, 2010-05-19 15:48:36]

On 2010/05/19 00:05:32, Olof Johansson wrote:
> PTAL, had to rebase due to other patches having been merged already.

Still the same changes, SLGTM

[Mandeep Singh Baines, 2010-05-19 18:25:12]

Is there any perfomance impact for this change?

[Olof Johansson, 2010-05-19 18:28:20]

From the Kconfig help:

config FUNCTION_TRACER
[...]
    help
      Enable the kernel to trace every kernel function. This is done
      by using a compiler feature to insert a small, 5-byte No-Operation
      instruction to the beginning of every kernel function, which NOP
      sequence is then dynamically patched into a tracer call when
      tracing is enabled by the administrator. If it's runtime disabled
      (the bootup default), then the overhead of the instructions is very
      small and not measurable even in micro-benchmarks.

[jrbarnette, 2010-05-19 18:47:00]

On May 19, 2010, at 11:25 AM, msb@chromium.org wrote:

> Is there any perfomance impact for this change?
>
I did some measurements with a similar configuration change on a
Lenovo x201, and on a system with internal SSD.  In both cases,
there seemed to be (possibly) a small degradation.  In absolute
terms, the impact is at the edge of human perception (about 20 ms).

We can discuss it more offline, but my basic conclusion is that
even if there's a measurable, statistically significant performance
cost, it can't be big enough to affect the user experience, and
that the visibility we get from this change will allow us to reduce
boot time by orders of magnitude more than we're losing.


> http://codereview.chromium.org/2086007/show

-- jrb

[jrbarnette, 2010-05-19 19:43:05]

On May 19, 2010, at 11:55 AM, Sam Leffler wrote:

> I'd agree on adding this for devel builds and then yank in production
> builds.  There is a space overhead in addition to runtime.  I'm adding
> it privately right now for diagnosing wireless issues.
>
What's the space overhead?

Thanks!


> -Sam
>
> On Wed, May 19, 2010 at 11:46 AM, Richard Barnette
> <jrbarnette@chromium.org> wrote:
>> On May 19, 2010, at 11:25 AM, msb@chromium.org wrote:
>>
>>> Is there any perfomance impact for this change?
>>>
>> I did some measurements with a similar configuration change on a
>> Lenovo x201, and on a system with internal SSD.  In both cases,
>> there seemed to be (possibly) a small degradation.  In absolute
>> terms, the impact is at the edge of human perception (about 20 ms).
>>
>> We can discuss it more offline, but my basic conclusion is that
>> even if there's a measurable, statistically significant performance
>> cost, it can't be big enough to affect the user experience, and
>> that the visibility we get from this change will allow us to reduce
>> boot time by orders of magnitude more than we're losing.
>>
>>
>>> http://codereview.chromium.org/2086007/show
>>
>> -- jrb
>>
>>
>>
>>

-- jrb

[Olof Johansson, 2010-05-19 19:45:04]

On 2010/05/19 19:43:05, jrbarnette wrote:

> What's the space overhead?

5 bytes per function.


-Olof

[Sam Leffler, 2010-05-19 20:15:18]

Looked like there was cache alignment overhead too.

-Sam

On Wed, May 19, 2010 at 12:45 PM,  <olofj@chromium.org> wrote:
> On 2010/05/19 19:43:05, jrbarnette wrote:
>
>> What's the space overhead?
>
> 5 bytes per function.
>
>
> -Olof
>
>
> http://codereview.chromium.org/2086007/show
>

[Mandeep Singh Baines, 2010-05-19 20:30:40]

LGTM

olofj@chromium.org (olofj@chromium.org) wrote:
> From the Kconfig help:
>
> config FUNCTION_TRACER
> [...]
>     help
>       Enable the kernel to trace every kernel function. This is done
>       by using a compiler feature to insert a small, 5-byte No-Operation
>       instruction to the beginning of every kernel function, which NOP
>       sequence is then dynamically patched into a tracer call when
>       tracing is enabled by the administrator. If it's runtime disabled
>       (the bootup default), then the overhead of the instructions is very
>       small and not measurable even in micro-benchmarks.
>
>
> http://codereview.chromium.org/2086007/show