Skip to content
  • Frederic Weisbecker's avatar
    perf_counter: Fix/complete ftrace event records sampling · f413cdb8
    Frederic Weisbecker authored
    
    
    This patch implements the kernel side support for ftrace event
    record sampling.
    
    A new counter sampling attribute is added:
    
       PERF_SAMPLE_TP_RECORD
    
    which requests ftrace events record sampling. In this case
    if a PERF_TYPE_TRACEPOINT counter is active and a tracepoint
    fires, we emit the tracepoint binary record to the
    perfcounter event buffer, as a sample.
    
    Result, after setting PERF_SAMPLE_TP_RECORD attribute from perf
    record:
    
     perf record -f -F 1 -a -e workqueue:workqueue_execution
     perf report -D
    
     0x21e18 [0x48]: event: 9
     .
     . ... raw event: size 72 bytes
     .  0000:  09 00 00 00 01 00 48 00 d0 c7 00 81 ff ff ff ff  ......H........
     .  0010:  0a 00 00 00 0a 00 00 00 21 00 00 00 00 00 00 00  ........!......
     .  0020:  2b 00 01 02 0a 00 00 00 0a 00 00 00 65 76 65 6e  +...........eve
     .  0030:  74 73 2f 31 00 00 00 00 00 00 00 00 0a 00 00 00  ts/1...........
     .  0040:  e0 b1 31 81 ff ff ff ff                          .......
    .
    0x21e18 [0x48]: PERF_EVENT_SAMPLE (IP, 1): 10: 0xffffffff8100c7d0 period: 33
    
    The raw ftrace binary record starts at offset 0020.
    
    Translation:
    
     struct trace_entry {
    	type		= 0x2b = 43;
    	flags		= 1;
    	preempt_count	= 2;
    	pid		= 0xa = 10;
    	tgid		= 0xa = 10;
     }
    
     thread_comm = "events/1"
     thread_pid  = 0xa = 10;
     func	    = 0xffffffff8131b1e0 = flush_to_ldisc()
    
    What will come next?
    
     - Userspace support ('perf trace'), 'flight data recorder' mode
       for perf trace, etc.
    
     - The unconditional copy from the profiling callback brings
       some costs however if someone wants no such sampling to
       occur, and needs to be fixed in the future. For that we need
       to have an instant access to the perf counter attribute.
       This is a matter of a flag to add in the struct ftrace_event.
    
     - Take care of the events recursivity! Don't ever try to record
       a lock event for example, it seems some locking is used in
       the profiling fast path and lead to a tracing recursivity.
       That will be fixed using raw spinlock or recursivity
       protection.
    
     - [...]
    
     - Profit! :-)
    
    Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
    Cc: Li Zefan <lizf@cn.fujitsu.com>
    Cc: Tom Zanussi <tzanussi@gmail.com>
    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Mike Galbraith <efault@gmx.de>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Pekka Enberg <penberg@cs.helsinki.fi>
    Cc: Gabriel Munteanu <eduard.munteanu@linux360.ro>
    Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
    Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
    f413cdb8