From 70015002ce6f35ef2535e88325aace40e38ab3db Mon Sep 17 00:00:00 2001 From: Kris Kennaway Date: Sun, 22 Apr 2007 06:20:12 +0000 Subject: [PATCH] Add some notes clarifying usage and a couple of known bugs --- tools/sched/schedgraph.py | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/tools/sched/schedgraph.py b/tools/sched/schedgraph.py index 3c26f941fb46..eb5f7308eb65 100644 --- a/tools/sched/schedgraph.py +++ b/tools/sched/schedgraph.py @@ -35,7 +35,15 @@ # - Add KTR_SCHED to KTR_COMPILE and KTR_MASK in your KERNCONF # - It is encouraged to increase KTR_ENTRIES size to 32768 to gather # enough information for analysis. -# - Rebuild kernel with proper changes to KERNCONF. +# - Rebuild kernel with proper changes to KERNCONF and boot new kernel. +# - Run your workload to be profiled. +# - While the workload is continuing (i.e. before it finishes), disable +# KTR tracing by setting 'sysctl debug.ktr.mask=0'. This is necessary +# to avoid a race condition while running ktrdump, i.e. the KTR ring buffer +# will cycle a bit while ktrdump runs, and this confuses schedgraph because +# the timestamps appear to go backwards at some point. Stopping KTR logging +# while the workload is still running is to avoid wasting log entries on +# "idle" time at the end. # - Dump the trace to a file: 'ktrdump -ct > ktr.out' # - Run the python script: 'python schedgraph.py ktr.out' # @@ -44,6 +52,12 @@ # 2) Add bounding box style zoom. # 3) Click to center. # 4) Implement some sorting mechanism. +# +# BUGS: 1) Only 8 CPUs are supported, more CPUs require more choices of +# colours to represent them ;-) +# 2) Extremely short traces may cause a crash because the code +# assumes there is always at least one stathz entry logged, and +# the number of such events is used as a denominator ticksps = None status = None