Tracer Survey Questions

From eLinux.org
Jump to: navigation, search

Tracer Survey Questions

Here are some questions for characterizing the attributes of a Linux tracing system:

 (This list is not complete yet)
  • supported platforms:
    • what processors are supported:
      • i386
      • ia64
      • ppc
      • ppc64
      • sh
      • mips
      • sh64
    • does the system support multiple processors?
  • instrumentation
    • what parts of the system are instrumented:
      • is the kernel instrumented y/n
      • is user space instrumented y/n
      • are functions instrumented?
      • are specific locations instrumented (not necessarily at function boundaries)?
      • can trace points be inserted dynamically?
      • can trace points be inserted at function start?
      • can trace points be inserted at function end?
      • can trace points be inserted at other-than function boundaries?
    • can trace points be statically compiled into the kernel?
      • what is the mechanism for statically declaring a trace point? (macro, etc.)
      • what nomenclature is used to declare a trace point?
    • can trace points be dynamically inserted into the kernel?
      • what is the mechanism for dynamically inserting a new trace point?
      • what language is used to define a trace point?
          • is there a special trace-point definition language?
    • are there restrictions on where a trace point can be placed?
    • can a trace point be executed in interrupt context?
      • NMI context?
    • what clock is used for timestamps?
      • what is the clock resultion?
      • what is the timestamp size, in bits?
      • how is timestamp rollover handled?
  • event collection (logging)
    • where is trace data stored at the time of the event?
      • is the buffer in-kernel?
      • is the buffer dynamically or statically allocated?
      • is the buffer configurable in size?
      • is there a per-cpu buffer?
    • how is contention for the trace buffer handled?
    • can the trace data be "consumed" while the trace is active?
    • can trace data be aggregated instead of stored (ie. save counts, averages, etc. instead of events)?
      • what runtime aggregation is possible?
          • counts
          • averages
          • mapping (ie associate arrays)?
          • arbitrary math?
    • when is the earliest a trace can start (i.e. in the kernel boot process)?
      • at machine power-on?
      • at start_kernel?
      • after time_init?
      • at start of user-space?
      • after some user-space setup (mounting things, starting daemon, setting config, etc.)?
    • are event structures fixed or variable in size?
  • configuration
    • how is the trace configuration specified?
    • what is the system interface to start/stop a trace?
      • how is a trace started?
      • how is a trace stopped?
    • what runtime filters are available for trace data:
        • include/exclude specific trace points (by, e.g. mask)?
        • filter by pid?
        • filter by uid?
        • filter by cpuid?
        • filter by time (e.g. call duration)?
        • filter by interrupt context?
        • filter by event?
        • filter by event type or class?
        • filter by other? ARRAY(0x10169ddc)ARRAY(0x1015ea30)ARRAY(0x10169674)
    • how is the configuration set for a trace run, at the system level?
        • can the trace points be turned on/off at trace time?
        • can other filters be modifed at trace time?
    • what is the user interface to start/stop/configure a trace?
        • text
        • gui
        • network/serial/remote control
  • post-processing
    • what is the interface to collect the trace data for post-processing?
        • can the data be processed while the trace is active?
        • can the data be saved to disk?
        • can the data be transmitted over the network?
        • can the data be transmitted over some other connection (serial, usb, etc.)
    • what post-processing filters are available for trace data:
        • filter by pid?
        • filter by uid?
        • filter by cpuid?
        • filter by time?
        • filter by interrupt context?
        • filter by event?
        • filter by event type or class?
        • filter by other?
    • what is the format of trace data, during post-processing?
        • is it (still) binary?
        • is it ascii?
        • is it XML?
    • what post-processing presentations are available?
        • text
        • GUI
        • html/web format
        • graphics (e.g. png, svg)
    • what post-processing aggregation is available?
        • event counts/summaries?
            • by uid
            • by pid
            • by event type
        • statistics over time?
        • call trees?
    • what data analysis operations are supported:
        • sorting
        • searching
        • visualization
  • performance
    • what is the overhead on the system when tracing is not configured or active? (I assume 0, but you never know)
    • ... when tracing is configured but not active?
    • ... when only some subset of configured tracing is active?
    • what is the overhead when tracing is active?
    • what is the cost per event to log the data?
    • what is the cost per event to transfer the data for post-processing?
  • size
    • what is the average size of a trace log
    • what is the average number of entries in a trace log
  • need more questions here...