[lkml]   [2008]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] simple dprobe like markers for the kernel
    On Thu, 2008-07-10 at 11:30 -0400, Theodore Tso wrote:
    > On Thu, Jul 10, 2008 at 09:43:16AM -0500, James Bottomley wrote:
    > > No ... I'm used to optimisation strangeness. Again, I'm not trying to
    > > eliminate it because that would defeat the zero impact purpose. I'm
    > > trying to build a system that can be useful without any impact. The
    > > consequence is going to be that certain trace points can't be used
    > > because of the optimiser, but that's the tradeoff. As long as the
    > > people placing the trace points are subject matter experts in the
    > > subsystem (and actually using them) everything should be OK.
    > So as I understand things, your light-weight tracepoints are designed
    > for very performance-sensitive code paths where we don't want to
    > disturbe the optimization in the deactivated state. In
    > non-performance sensitive parts of the kernel, where cycle counting is
    > not so important, tracepoints can and probably should still be used.
    > So I don't think you were proposing eliminating the current kernel
    > markers in favor of this approach, yes?

    That's right ... I started from the position that the current markers
    were too heavy for an I/O subsystem, but I'm sure they have many other

    > When you said a tool could determine if the tracepoint had gotten
    > optimized away, or the variables were no longer present, I assume you
    > meant at compile time, right?

    Yes and no. Yes because a tool will be able to detect the problems, but
    no if you're thinking an actual kernel compile would do it (unless some
    tool is designed for this and integrated into the build ... the obvious
    tool is systemtap, but that might cause some heartburn).

    > So with the right tool built into the
    > kbuild infrastructure, if we could simply print warnings when
    > tracepoints had gotten optimized away, that would make the your simple
    > tracepoints quite safe for general use, I would think.

    Yes ... but someone has to come up with the tool. I suppose rebuilding
    the line number matrix and finding the variables at the location is easy
    mechanical dwarf stuff ... but it will give the kernel build a lot of
    external dependencies it didn't have before.

    Plus, this level of checking can only be done if dwarf is generated


     \ /
      Last update: 2008-07-10 17:59    [W:0.022 / U:10.876 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site