lkml.org 
[lkml]   [2008]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Kernel marker has no performance impact on ia64.
    Hi -

    On Thu, Jun 12, 2008 at 01:05:52PM -0400, Masami Hiramatsu wrote:
    > [...]
    > >> "sched_switch(struct task_struct * next, struct task_struct * prev)":"next %p prev %p"
    > >> out of tree. Thus, you can use the printf-style format parser.
    > >
    > > That's an interesting idea, but errors in this table would themselves
    > > only be caught at C compilation time.

    > Hmm, why would you think so? I think if we can't find corresponding
    > entry from the lookup table, it becomes an error.

    Sure, but if the entry exists but is wrong, we'd emit C code that
    won't compile.


    > [...] Even if you use trace_mark() markers, you have to post a
    > kernel patch which passes the prev->pid to the marking point and to
    > discuss it. for example,
    > DEFINE_TRACE(sched_switch, (int prev_pid, int next_pid), prev_pid, next_pid)

    (If it were up to me, I would add the task pointers too, which
    debuginfo-less systemtap could ignore but other tracers may use.)


    > But it might not so general, we have to discuss what parameters are
    > enough good for each marking point.

    That's exactly what the "lttng instrumentation markers" threads from
    the recent past had started.


    - FChE


    \
     
     \ /
      Last update: 2008-06-12 19:53    [W:0.024 / U:119.108 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site