06 Oct, 2020

1 commit

  • Currently, sythetic events only support static string fields such as:

    # echo 'test_latency u64 lat; char somename[32]' > /sys/kernel/debug/tracing/synthetic_events

    Which is fine, but wastes a lot of space in the event.

    It also prevents the most commonly-defined strings in the existing
    trace events e.g. those defined using __string(), from being passed to
    synthetic events via the trace() action.

    With this change, synthetic events with dynamic fields can be defined:

    # echo 'test_latency u64 lat; char somename[]' > /sys/kernel/debug/tracing/synthetic_events

    And the trace() action can be used to generate events using either
    dynamic or static strings:

    # echo 'hist:keys=name:lat=common_timestamp.usecs-$ts0:onmatch(sys.event).test_latency($lat,name)' > /sys/kernel/debug/tracing/events

    The synthetic event dynamic strings are implemented in the same way as
    the existing __data_loc strings and appear as such in the format file.

    [ : added __set_synth_event_print_fmt() changes:

    I added the following to make it work with trace-cmd. Dynamic strings
    must have __get_str() for events in the print_fmt otherwise it can't be
    parsed correctly. ]

    Link: https://lore.kernel.org/r/cover.1601588066.git.zanussi@kernel.org
    Link: https://lkml.kernel.org/r/3ed35b6d0e390f5b94cb4a9ba1cc18f5982ab277.1601848695.git.zanussi@kernel.org

    Tested-by: Axel Rasmussen
    Signed-off-by: Tom Zanussi
    Signed-off-by: Steven Rostedt (VMware)

    Tom Zanussi
     

21 Feb, 2020

2 commits

  • The test code that tests synthetic event creation pushes in as one of its
    test fields the current CPU using "smp_processor_id()". As this is just
    something to see if the value is correctly passed in, and the actual CPU
    used does not matter, use raw_smp_processor_id(), otherwise with debug
    preemption enabled, a warning happens as the smp_processor_id() is called
    without preemption enabled.

    Link: http://lkml.kernel.org/r/20200220162950.35162579@gandalf.local.home

    Reviewed-by: Tom Zanussi
    Signed-off-by: Steven Rostedt (VMware)

    Steven Rostedt (VMware)
     
  • synth_event_trace() is the varargs version of synth_event_trace_array(),
    which takes an array of u64, as do synth_event_add_val() et al.

    To not only be consistent with those, but also to address the fact
    that synth_event_trace() expects every arg to be of the same type
    since it doesn't also pass in e.g. a format string, the caller needs
    to make sure all args are of the same type, u64. u64 is used because
    it needs to accomodate the largest type available in synthetic events,
    which is u64.

    This fixes the bug reported by the kernel test robot/Rong Chen.

    Link: https://lore.kernel.org/lkml/20200212113444.GS12867@shao2-debian/
    Link: http://lkml.kernel.org/r/894c4e955558b521210ee0642ba194a9e603354c.1581720155.git.zanussi@kernel.org

    Fixes: 9fe41efaca084 ("tracing: Add synth event generation test module")
    Reported-by: kernel test robot
    Signed-off-by: Tom Zanussi
    Signed-off-by: Steven Rostedt (VMware)

    Tom Zanussi
     

30 Jan, 2020

1 commit

  • Add a test module that checks the basic functionality of the in-kernel
    synthetic event generation API by generating and tracing synthetic
    events from a module.

    Link: http://lkml.kernel.org/r/fcb4dd9eb9eefb70ab20538d3529d51642389664.1580323897.git.zanussi@kernel.org

    Acked-by: Masami Hiramatsu
    Signed-off-by: Tom Zanussi
    Signed-off-by: Steven Rostedt (VMware)

    Tom Zanussi