aboutsummaryrefslogtreecommitdiffstats
path: root/kernel/trace/trace.h
diff options
context:
space:
mode:
authorFrederic Weisbecker <fweisbec@gmail.com>2009-02-24 21:22:28 -0500
committerIngo Molnar <mingo@elte.hu>2009-02-25 07:40:58 -0500
commitb04cc6b1f6398b0e0b60d37e27ce51b4899672ec (patch)
tree61d5bd59b364913f5a124d25925b908c5deaf871 /kernel/trace/trace.h
parent2b1b858f690d6369a59ad241335eeedec6eb0c8c (diff)
tracing/core: introduce per cpu tracing files
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: Frederic 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: Ingo Molnar <mingo@elte.hu>
Diffstat (limited to 'kernel/trace/trace.h')
-rw-r--r--kernel/trace/trace.h3
1 files changed, 3 insertions, 0 deletions
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index eed732c151f..508235a39da 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -395,6 +395,8 @@ struct trace_seq {
395 unsigned int readpos; 395 unsigned int readpos;
396}; 396};
397 397
398#define TRACE_PIPE_ALL_CPU -1
399
398/* 400/*
399 * Trace iterator - used by printout routines who present trace 401 * Trace iterator - used by printout routines who present trace
400 * results to users and which routines might sleep, etc: 402 * results to users and which routines might sleep, etc:
@@ -404,6 +406,7 @@ struct trace_iterator {
404 struct tracer *trace; 406 struct tracer *trace;
405 void *private; 407 void *private;
406 struct ring_buffer_iter *buffer_iter[NR_CPUS]; 408 struct ring_buffer_iter *buffer_iter[NR_CPUS];
409 int cpu_file;
407 410
408 /* The below is zeroed out in pipe_read */ 411 /* The below is zeroed out in pipe_read */
409 struct trace_seq seq; 412 struct trace_seq seq;