summaryrefslogtreecommitdiffstats
path: root/kernel/trace/trace.h
diff options
context:
space:
mode:
authorFrederic Weisbecker <fweisbec@gmail.com>2009-02-25 03:22:28 +0100
committerIngo Molnar <mingo@elte.hu>2009-02-25 13:40:58 +0100
commitb04cc6b1f6398b0e0b60d37e27ce51b4899672ec (patch)
tree61d5bd59b364913f5a124d25925b908c5deaf871 /kernel/trace/trace.h
parentMerge branch 'tip/tracing/ftrace' of git://git.kernel.org/pub/scm/linux/kerne... (diff)
downloadlinux-b04cc6b1f6398b0e0b60d37e27ce51b4899672ec.tar.xz
linux-b04cc6b1f6398b0e0b60d37e27ce51b4899672ec.zip
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 eed732c151fc..508235a39da6 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -395,6 +395,8 @@ struct trace_seq {
unsigned int readpos;
};
+#define TRACE_PIPE_ALL_CPU -1
+
/*
* Trace iterator - used by printout routines who present trace
* results to users and which routines might sleep, etc:
@@ -404,6 +406,7 @@ struct trace_iterator {
struct tracer *trace;
void *private;
struct ring_buffer_iter *buffer_iter[NR_CPUS];
+ int cpu_file;
/* The below is zeroed out in pipe_read */
struct trace_seq seq;