• Frederic Weisbecker's avatar
    tracing/core: introduce per cpu tracing files · b04cc6b1
    Frederic Weisbecker authored
    Impact: split up tracing output per cpu
    
    Currently, on the tracing debugfs directory, three files are
    available to the user to let him extracting the trace output:
    
    - trace is an iterator through the ring-buffer. It's a reader
      but not a consumer It doesn't block when no more traces are
      available.
    
    - trace pretty similar to the former, except that it adds more
      informations such as prempt count, irq flag, ...
    
    - trace_pipe is a reader and a consumer, it will also block
      waiting for traces if necessary (heh, yes it's a pipe).
    
    The traces coming from different cpus are curretly mixed up
    inside these files. Sometimes it messes up the informations,
    sometimes it's useful, depending on what does the tracer
    capture.
    
    The tracing_cpumask file is useful to filter the output and
    select only the traces captured a custom defined set of cpus.
    But still it is not enough powerful to extract at the same time
    one trace buffer per cpu.
    
    So this patch creates a new directory: /debug/tracing/per_cpu/.
    
    Inside this directory, you will now find one trace_pipe file and
    one trace file per cpu.
    
    Which means if you have two cpus, you will have:
    
     trace0
     trace1
     trace_pipe0
     trace_pipe1
    
    And of course, reading these files will have the same effect
    than with the usual tracing files, except that you will only see
    the traces from the given cpu.
    
    The original all-in-one cpu trace file are still available on
    their original place.
    
    Until now, only one consumer was allowed on trace_pipe to avoid
    racy consuming on the ring-buffer. Now the approach changed a
    bit, you can have only one consumer per cpu.
    
    Which means you are allowed to read concurrently trace_pipe0 and
    trace_pipe1 But you can't have two readers on trace_pipe0 or
    trace_pipe1.
    
    Following the same logic, if there is one reader on the common
    trace_pipe, you can not have at the same time another reader on
    trace_pipe0 or in trace_pipe1. Because in trace_pipe is already
    a consumer in all cpu buffers in essence.
    Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
    b04cc6b1
trace.h 19.6 KB