[RFC PATCH 26/30 v3] Add context switch marker to sched.c

From: Steven Rostedt
Date: Tue Jan 15 2008 - 15:57:42 EST


The trace facilities here needs a hook into the context switch events.
Since Mathieu Desnoyers has been working on markers for LTTng, I figured
I take the marker he has in his patch queue.

The thing is that he only records the prev's pid, next's pid, and prev's state.
It would suit me better if it simply passed in the prev and next pointer.
Since I don't want to add markers all over the place to get the information
that I need. The latency tracer only turns on for short periods of time
and already takes up enough memory to store the traces, I don't want to add
databases keeping track of changes such as priorities, and such, when I
could simply get that information from a context switch.

Yes, that would slow down all context switches a little when tracing is on,
but for this, it should be sufficient.

Anyway, I'm not about to start a war on this, so I simply folded and will
use Mathieu's proposed marker instead. I'm just worried that in the future
we will want more information about the processes in the context switch but
will still be stuck with just the pid's and state.

Signed-off-by: Steven Rostedt <srostedt@xxxxxxxxxx>
Cc: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxx>
---
kernel/sched.c | 3 +++
1 file changed, 3 insertions(+)

Index: linux-compile.git/kernel/sched.c
===================================================================
--- linux-compile.git.orig/kernel/sched.c 2008-01-14 14:57:33.000000000 -0500
+++ linux-compile.git/kernel/sched.c 2008-01-15 00:15:45.000000000 -0500
@@ -1933,6 +1933,9 @@ context_switch(struct rq *rq, struct tas
struct mm_struct *mm, *oldmm;

prepare_task_switch(rq, prev, next);
+ trace_mark(kernel_sched_schedule,
+ "prev_pid %d next_pid %d prev_state %ld",
+ prev->pid, next->pid, prev->state);
mm = next->mm;
oldmm = prev->active_mm;
/*

--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/