]> git.openfabrics.org - ~emulex/infiniband.git/commitdiff
perf: cleanup some Documentation
authorRandy Dunlap <randy.dunlap@oracle.com>
Wed, 31 Mar 2010 18:31:00 +0000 (11:31 -0700)
committerArnaldo Carvalho de Melo <acme@redhat.com>
Thu, 8 Apr 2010 14:34:26 +0000 (11:34 -0300)
Correct typos in perf bench & perf sched help text.

Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <20100331113100.cc898487.randy.dunlap@oracle.com>
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
tools/perf/Documentation/perf-bench.txt
tools/perf/Documentation/perf-sched.txt

index ae525ac5a2ceabdc5612e0ecd631e475619205f5..0181dddf6b61438d3070939f4c271e8b16cd6b6e 100644 (file)
@@ -19,12 +19,12 @@ COMMON OPTIONS
 -f::
 --format=::
 Specify format style.
-Current available format styles are,
+Current available format styles are:
 
 'default'::
 Default style. This is mainly for human reading.
 ---------------------
-% perf bench sched pipe                      # with no style specify
+% perf bench sched pipe                      # with no style specified
 (executing 1000000 pipe operations between two tasks)
         Total time:5.855 sec
                 5.855061 usecs/op
@@ -79,7 +79,7 @@ options (20 sender and receiver processes per group)
 
       Total time:0.308 sec
 
-% perf bench sched messaging -t -g 20        # be multi-thread,with 20 groups
+% perf bench sched messaging -t -g 20        # be multi-thread, with 20 groups
 (20 sender and receiver threads per group)
 (20 groups == 800 threads run)
 
index 1ce79198997b00248c077a5ac46af22a0ab461fb..8417644a6166b9fcd071b88eebb9dd46f00b8a1f 100644 (file)
@@ -12,7 +12,7 @@ SYNOPSIS
 
 DESCRIPTION
 -----------
-There's four variants of perf sched:
+There are four variants of perf sched:
 
   'perf sched record <command>' to record the scheduling events
   of an arbitrary workload.
@@ -27,7 +27,7 @@ There's four variants of perf sched:
   via perf sched record. (this is done by starting up mockup threads
   that mimic the workload based on the events in the trace. These
   threads can then replay the timings (CPU runtime and sleep patterns)
-  of the workload as it occured when it was recorded - and can repeat
+  of the workload as it occurred when it was recorded - and can repeat
   it a number of times, measuring its performance.)
 
 OPTIONS