lkml.org 
[lkml]   [2006]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108
    Mathieu Desnoyers wrote:
    > > Trace event headers are very similar between both LTT and LKET which is
    > > good in other to get some synergy between our projects. One thing that
    > > LKET has on each trace event that LTT doesn't is the tid and CPU id of
    > > each event. We find this extremely useful for post-processing. Also,
    > > why have the event_size on every event taken? Why not describe the
    > > event during the trace header and remove this redundant information from
    > > the event header and save some trace file space.
    > >
    >
    > A standard event header has to have only crucial information, nothing more, or
    > it becomes bloated and quickly grow trace size. We decided not to put tid and
    > CPU id in the event header because tid is already available with the schedchange
    > events at post-processing time and CPU id is already available too, as we have
    > per CPU buffers.
    >

    We still keep the CPU id because LKET still support ASCII tracing which
    mixes the output of all the CPUs together. It is still debatable
    whether this is a useful feature or not though. If we remove ASCII
    event tracing from LKET, we could remove CPU id from the event header as
    well.

    The tid we still include because LKET supports turning on individual
    tracepoints unlike LTT, which if I remember correctly turns on all the
    tracepoint that are compiled into the running kernel. Since the user is
    free to chose which tracepoints he wants to use for his workload, we can
    not guarantee that scheduler tracepoints are going to be available. We
    consider taking the tid as one of those absolute minimum pieces of data
    required to do meaningful analysis.

    We chose to control performance and trace output size by letting users
    have control of number of tracepoint he can activate at any given time.
    This is important to us since we plan to add many dynamic tracepoints to
    different sub-systems (filesystem, device drivers, core kernel
    facilities, etc...). Turning on all of these tracepoint at the same
    time would slow down the system to much and change the performance
    characteristics of the environment being studied.
    > The event size is completely unnecessary, but in reality very, very useful to
    > authenticate the correspondance between the size of the data recorded by the
    > kernel and the size of data the viewer thinks it is reading. Think of it as a
    > consistency check between kernel and viewer algorithms.
    >

    I understand. But if the size of each event is fixed, why would you
    expect the data sizes that the tool reports in the trace header for each
    event to change over the course of a trace. If the data on the per-CPU
    buffers is serialized, a similar authentication could be done using the
    timestamp by checking the timestamps of the events before and after the
    current event, thus validating the current timestamp as well as the size
    offset of the previous event. Just a thought.

    -JRS
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-09-19 17:09    [W:6.040 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site