[lkml]   [2011]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 00/14] [GIT PULL][v2.6.39] tracing/filter: More robust filtering
    On Tue, 2011-02-15 at 05:44 +0100, Ingo Molnar wrote:
    > hi Steve,
    > * Steven Rostedt <> wrote:
    > > Steven Rostedt (14):
    > > tracing/filter: Have no filter return a match
    > > tracing/filter: Move OR and AND logic out of fn() method
    > > tracing/filter: Dynamically allocate preds
    > > tracing/filter: Call synchronize_sched() just once for system filters
    > > tracing/filter: Allocate the preds in an array
    > > tracing/filter: Free pred array on disabling of filter
    > > tracing/filter: Use a tree instead of stack for filter_match_preds()
    > > tracing/filter: Optimize short ciruit check
    > > tracing/filter: Check the created pred tree
    > > tracing/filter: Optimize filter by folding the tree
    > > tracing/filter: Move MAX_FILTER_PRED to local tracing directory
    > > tracing/filter: Increase the max preds to 2^14
    > > tracing/filter: Swap entire filter of events
    > > tracing/filter: Remove synchronize_sched() from __alloc_preds()
    > I finally got around testing the various tracing filter features we have.

    [ snip all the perf output ]

    > So ... i have to say that this tracing filter business is unusable crap from a user
    > POV right now and i see no reason to pull *anything* in this area until it does not
    > get improved to *much* better levels of usability and utility.
    > Nobody could *ever* have tested this with a 'naive but curious user' hat on and this
    > is really sad. We need to do much better!

    Sorry I did not work with perf in writing this code. I was using the
    debugfs directly. I figured that any improvement I made there would also
    improve perf as I tried to make sure the perf hooks into that code were
    updated too.

    My question is, did this patch set cause any of the perf problems or did
    these problems always exist?

    I'm just saying that perf is not the only user. And to deny improvements
    in the code because one user does not currently work well with them is
    just hindering progress.

    There happens to be real users out in the world that are still using
    ftrace. I see no reason to stop improving it because your goal is to
    have everyone move to perf.

    Thanks for letting me waste three days on developing this. I even posted
    an RFC a while back, and no one complained then.

    -- Steve

     \ /
      Last update: 2011-02-15 14:35    [W:0.022 / U:2.992 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site