lkml.org 
[lkml]   [2010]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [ANNOUNCE] New utility: 'trace'
    From
    Date
    On Wed, 2010-11-17 at 16:43 +0100, Peter Zijlstra wrote:
    > On Wed, 2010-11-17 at 10:10 -0500, Steven Rostedt wrote:
    > >
    > > Right, the problem with filtering is what do we want to filter, and what
    > > about copying?
    > >
    > > Currently, we copy the data into the buffer and then filter on that
    > > data. We could also easily filter on the parameters of the tracepoint,
    > > but sometimes those parameters do not match the final output (as the
    > > case with sched_switch). Do we copy the data into a separate "per cpu"
    > > temp buffer, and figure out the filter then? And if the filter is fine,
    > > then copy into the buffer. This obviously is slow, due to the multiple
    > > copies. We could do this only if the filtering is enabled.
    >
    > Right, so what is the primary purpose of this filtering stuff? As it
    > stands it makes stuff terribly slow, so you add overhead but the win
    > (presumably) is less data output, is that a sane trade-off?

    I've actually used filtering too. Not for speed up, but because I was
    recording a lot of data and the reader could not keep up. By filtering,
    I was able to get all the relevant information without needing to make
    the kernel buffer a Gig.

    -- Steve




    \
     
     \ /
      Last update: 2010-11-17 17:17    [W:4.099 / U:1.236 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site