lkml.org 
[lkml]   [2013]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 6/6] x86: Allow disabling HW_BREAKPOINTS and PERF_EVENTS

    * Steven Rostedt <rostedt@goodmis.org> wrote:

    > On Tue, Oct 08, 2013 at 08:59:38AM +0200, Ingo Molnar wrote:
    > >
    > > Secondly and more importantly, visualized with relative sizes, in a
    > > feature matrix, makes it clearer what's going on with vmlinux .text:
    > >
    > > perf-OFF perf-ON
    > >
    > > ftrace-OFF 0 +151k
    > >
    > > ftrace-ON +897k +1142k
    > >
    > > So basically ftrace is causing a big chunk of the instrumentation size
    > > increase. With tons of tracers and lots of kernel subsystems built into
    > > your .config that's a lot of nice instrumentation functionality and it's
    > > thus also a natural end result IMO.
    >
    > I'm curious what you turned on for between the "ftrace-OFF" and "ftrace-ON"?

    ON: all the tracing bits in Andi's original config - which had most
    tracing options enabled AFAICS.

    OFF: all of it turned off.

    I don't think there's anything inherently wrong with 3000+ tracepoints
    built into the kernel using up a fair amount of cold-path space. We should
    try to compress it all, but it's a hell of a lot real functionality.

    > The one thing that you didn't post was CONFIG_EVENT_TRACING. This is
    > where a lot of bloat can come from, as this enables the infrastructure
    > for tracepoints. This is also needed by perf to trace most sw events.

    Correct.

    EVENT_TRACING was on - Andi did not post his .config publicly, but you can
    get something fairly close to his config by doing this:

    make defconfig
    cat config-options.txt >> .config
    make oldconfig

    where 'config-options.txt' is the short list of options I appended to my
    mail.

    > The trace event infrastructure that both perf and ftrace uses (as well
    > as other tracers and tools) is well known to cause bloat in the kernel.
    > There's patches to help make it more bearable, but there's more work to
    > be done.

    It's 3000+ very nice tracepoints - which is a huge multiplier, so we
    should not expect any miracles - it's a whole lot of good functionality.
    Subsystems can decide whether they want to expose their tracepoints or
    not.

    Thanks,

    Ingo


    \
     
     \ /
      Last update: 2013-10-08 22:01    [W:2.366 / U:0.700 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site