| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <1297712520.23343.73.camel@gandalf.stny.rr.com>
Date: Mon, 14 Feb 2011 14:42:00 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: linux-kernel@...r.kernel.org
Cc: Ingo Molnar <mingo@...e.hu>,
Andrew Morton <akpm@...ux-foundation.org>,
Frederic Weisbecker <fweisbec@...il.com>,
Peter Zijlstra <peterz@...radead.org>, Greg KH <greg@...ah.com>
Subject: Re: [PATCH 09/10] tracing: Remove obsolete sched_switch tracer
On Tue, 2011-02-08 at 17:16 -0500, Steven Rostedt wrote:
> plain text document attachment
> (0009-tracing-Remove-obsolete-sched_switch-tracer.patch)
> From: Steven Rostedt <srostedt@...hat.com>
>
> The trace events sched_switch and sched_wakeup do the same thing
> as the stand alone sched_switch tracer does. It is no longer needed.
Hmm, is this the right thing to do, or should we do the "WARN_ONCE()"
when it is used, and give it a year to remove it?
-- Steve
>
> Signed-off-by: Steven Rostedt <rostedt@...dmis.org>
> ---
> Documentation/trace/ftrace.txt | 110 -------------------------------------
> kernel/trace/trace_sched_switch.c | 48 ----------------
> 2 files changed, 0 insertions(+), 158 deletions(-)
>
> diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt
> index 557c1ed..65eddb7 100644
> --- a/Documentation/trace/ftrace.txt
> +++ b/Documentation/trace/ftrace.txt
> @@ -202,10 +202,6 @@ Here is the list of current tracers that may be configured.
> to draw a graph of function calls similar to C code
> source.
>
> - "sched_switch"
> -
> - Traces the context switches and wakeups between tasks.
> -
> "irqsoff"
>
> Traces the areas that disable interrupts and saves
> @@ -273,39 +269,6 @@ format, the function name that was traced "path_put" and the
> parent function that called this function "path_walk". The
> timestamp is the time at which the function was entered.
>
> -The sched_switch tracer also includes tracing of task wakeups
> -and context switches.
> -
> - ksoftirqd/1-7 [01] 1453.070013: 7:115:R + 2916:115:S
> - ksoftirqd/1-7 [01] 1453.070013: 7:115:R + 10:115:S
> - ksoftirqd/1-7 [01] 1453.070013: 7:115:R ==> 10:115:R
> - events/1-10 [01] 1453.070013: 10:115:S ==> 2916:115:R
> - kondemand/1-2916 [01] 1453.070013: 2916:115:S ==> 7:115:R
> - ksoftirqd/1-7 [01] 1453.070013: 7:115:S ==> 0:140:R
> -
> -Wake ups are represented by a "+" and the context switches are
> -shown as "==>". The format is:
> -
> - Context switches:
> -
> - Previous task Next Task
> -
> - <pid>:<prio>:<state> ==> <pid>:<prio>:<state>
> -
> - Wake ups:
> -
> - Current task Task waking up
> -
> - <pid>:<prio>:<state> + <pid>:<prio>:<state>
> -
> -The prio is the internal kernel priority, which is the inverse
> -of the priority that is usually displayed by user-space tools.
> -Zero represents the highest priority (99). Prio 100 starts the
> -"nice" priorities with 100 being equal to nice -20 and 139 being
> -nice 19. The prio "140" is reserved for the idle task which is
> -the lowest priority thread (pid 0).
> -
> -
> Latency trace format
> --------------------
>
> @@ -491,79 +454,6 @@ x494] <- /root/a.out[+0x4a8] <- /lib/libc-2.7.so[+0x1e1a6]
> latencies, as described in "Latency
> trace format".
>
> -sched_switch
> -------------
> -
> -This tracer simply records schedule switches. Here is an example
> -of how to use it.
> -
> - # echo sched_switch > current_tracer
> - # echo 1 > tracing_enabled
> - # sleep 1
> - # echo 0 > tracing_enabled
> - # cat trace
> -
> -# tracer: sched_switch
> -#
> -# TASK-PID CPU# TIMESTAMP FUNCTION
> -# | | | | |
> - bash-3997 [01] 240.132281: 3997:120:R + 4055:120:R
> - bash-3997 [01] 240.132284: 3997:120:R ==> 4055:120:R
> - sleep-4055 [01] 240.132371: 4055:120:S ==> 3997:120:R
> - bash-3997 [01] 240.132454: 3997:120:R + 4055:120:S
> - bash-3997 [01] 240.132457: 3997:120:R ==> 4055:120:R
> - sleep-4055 [01] 240.132460: 4055:120:D ==> 3997:120:R
> - bash-3997 [01] 240.132463: 3997:120:R + 4055:120:D
> - bash-3997 [01] 240.132465: 3997:120:R ==> 4055:120:R
> - <idle>-0 [00] 240.132589: 0:140:R + 4:115:S
> - <idle>-0 [00] 240.132591: 0:140:R ==> 4:115:R
> - ksoftirqd/0-4 [00] 240.132595: 4:115:S ==> 0:140:R
> - <idle>-0 [00] 240.132598: 0:140:R + 4:115:S
> - <idle>-0 [00] 240.132599: 0:140:R ==> 4:115:R
> - ksoftirqd/0-4 [00] 240.132603: 4:115:S ==> 0:140:R
> - sleep-4055 [01] 240.133058: 4055:120:S ==> 3997:120:R
> - [...]
> -
> -
> -As we have discussed previously about this format, the header
> -shows the name of the trace and points to the options. The
> -"FUNCTION" is a misnomer since here it represents the wake ups
> -and context switches.
> -
> -The sched_switch file only lists the wake ups (represented with
> -'+') and context switches ('==>') with the previous task or
> -current task first followed by the next task or task waking up.
> -The format for both of these is PID:KERNEL-PRIO:TASK-STATE.
> -Remember that the KERNEL-PRIO is the inverse of the actual
> -priority with zero (0) being the highest priority and the nice
> -values starting at 100 (nice -20). Below is a quick chart to map
> -the kernel priority to user land priorities.
> -
> - Kernel Space User Space
> - ===============================================================
> - 0(high) to 98(low) user RT priority 99(high) to 1(low)
> - with SCHED_RR or SCHED_FIFO
> - ---------------------------------------------------------------
> - 99 sched_priority is not used in scheduling
> - decisions(it must be specified as 0)
> - ---------------------------------------------------------------
> - 100(high) to 139(low) user nice -20(high) to 19(low)
> - ---------------------------------------------------------------
> - 140 idle task priority
> - ---------------------------------------------------------------
> -
> -The task states are:
> -
> - R - running : wants to run, may not actually be running
> - S - sleep : process is waiting to be woken up (handles signals)
> - D - disk sleep (uninterruptible sleep) : process must be woken up
> - (ignores signals)
> - T - stopped : process suspended
> - t - traced : process is being traced (with something like gdb)
> - Z - zombie : process waiting to be cleaned up
> - X - unknown
> -
> -
> ftrace_enabled
> --------------
>
> diff --git a/kernel/trace/trace_sched_switch.c b/kernel/trace/trace_sched_switch.c
> index 8f758d0..7e62c0a 100644
> --- a/kernel/trace/trace_sched_switch.c
> +++ b/kernel/trace/trace_sched_switch.c
> @@ -247,51 +247,3 @@ void tracing_sched_switch_assign_trace(struct trace_array *tr)
> ctx_trace = tr;
> }
>
> -static void stop_sched_trace(struct trace_array *tr)
> -{
> - tracing_stop_sched_switch_record();
> -}
> -
> -static int sched_switch_trace_init(struct trace_array *tr)
> -{
> - ctx_trace = tr;
> - tracing_reset_online_cpus(tr);
> - tracing_start_sched_switch_record();
> - return 0;
> -}
> -
> -static void sched_switch_trace_reset(struct trace_array *tr)
> -{
> - if (sched_ref)
> - stop_sched_trace(tr);
> -}
> -
> -static void sched_switch_trace_start(struct trace_array *tr)
> -{
> - sched_stopped = 0;
> -}
> -
> -static void sched_switch_trace_stop(struct trace_array *tr)
> -{
> - sched_stopped = 1;
> -}
> -
> -static struct tracer sched_switch_trace __read_mostly =
> -{
> - .name = "sched_switch",
> - .init = sched_switch_trace_init,
> - .reset = sched_switch_trace_reset,
> - .start = sched_switch_trace_start,
> - .stop = sched_switch_trace_stop,
> - .wait_pipe = poll_wait_pipe,
> -#ifdef CONFIG_FTRACE_SELFTEST
> - .selftest = trace_selftest_startup_sched_switch,
> -#endif
> -};
> -
> -__init static int init_sched_switch_trace(void)
> -{
> - return register_tracer(&sched_switch_trace);
> -}
> -device_initcall(init_sched_switch_trace);
> -
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists