Commit 909ede4f authored by Augusto Caringi's avatar Augusto Caringi

Fix random small typos and mistakes in man pages

parent 8f7f8214
......@@ -21,7 +21,7 @@ CONFIG_BPF and bpftrace.
.TP
Trace block device I/O (disk I/O), and print a latency histogram on Ctrl-C:
#
.B biolatency
.B biolatency.bt
.SH FIELDS
.TP
1st, 2nd
......@@ -31,7 +31,7 @@ This is a range of latency, in microseconds (shown in "[...)" set notation).
A column showing the count of operations in this range.
.TP
4th
This is an ASCII histogram representing the count colimn.
This is an ASCII histogram representing the count column.
.SH OVERHEAD
Since block device I/O usually has a relatively low frequency (< 10,000/s),
the overhead for this tool is expected to be negligible. For high IOPS storage
......
......@@ -26,10 +26,10 @@ TIME
Time of the I/O completion, in milliseconds since program start.
.TP
COMM
Issuing process name. This often identifies the issuing applicaion process, but I/O may be initiated from kernel threads only.
Issuing process name. This often identifies the issuing application process, but I/O may be initiated from kernel threads only.
.TP
PID
Issuing process ID. This often identifies the issuing applicaion process, but I/O may be initiated from kernel threads only.
Issuing process ID. This often identifies the issuing application process, but I/O may be initiated from kernel threads only.
.TP
ARGS
Process name and arguments (16 word maximum).
......
......@@ -30,7 +30,7 @@ This is a range of I/O sizes, in Kbytes (shown in "[...)" set notation).
A column showing the count of I/O in this range.
.TP
4th
This is an ASCII histogram representing the count colimn.
This is an ASCII histogram representing the count column.
.SH OVERHEAD
Since block device I/O usually has a relatively low frequency (< 10,000/s),
the overhead for this tool is expected to be low or negligible. For high IOPS
......
......@@ -15,7 +15,7 @@ CONFIG_BPF, bpftrace.
.TP
Trace all capability checks system-wide:
#
.B capable
.B capable.bt
.SH FIELDS
.TP
TIME(s)
......
......@@ -16,7 +16,7 @@ CONFIG_BPF and bpftrace.
.TP
Sample CPUs and print a summary on Ctrl-C:
#
.B cpuwalk
.B cpuwalk.bt
.SH FIELDS
.TP
1st, 2nd
......@@ -26,7 +26,7 @@ The CPU is shown in the first field, after the "[". Disregard the second field.
A column showing the number of samples for this CPU.
.TP
4th
This is an ASCII histogram representing the count colimn.
This is an ASCII histogram representing the count column.
.SH OVERHEAD
This should be negligible.
.SH SOURCE
......
......@@ -21,7 +21,7 @@ CONFIG_BPF and bcc.
.TP
Trace all dcache lookups:
#
.B dcsnoop
.B dcsnoop.bt
.SH FIELDS
.TP
TIME(ms)
......
.TH execsnoop 8 "2018-09-11" "USER COMMANDS"
.SH NAME
execsnoop.bt \- Trace signals issued by the kill() syscall. Uses bpftrace/eBPF.
execsnoop.bt \- Trace new processes via exec() syscalls. Uses bpftrace/eBPF.
.SH SYNOPSIS
.B execsnoop.bt
.SH DESCRIPTION
......
......@@ -15,19 +15,19 @@ CONFIG_BPF and bpftrace.
.TP
Print system load averages every second:
#
.B loads
.B loads.bt
.SH FIELDS
.TP
HH:MM:SS
Each output line includes time of printing in "HH:MM:SS" format.
.TP
load averages:
These are exponentially-damped moving sum averages of the system loads.
These are exponentially-damped moving sum averages of the system loads.
Load is a measurement of demand on system resources, which include CPUs and
other resources that are accessed with the kernel in an uninterruptible state
(TASK_UNINTERRUPTIBLE), which includes types of disk I/O and lock accessses.
(TASK_UNINTERRUPTIBLE), which includes types of disk I/O and lock accesses.
Linux load averages originally reflected CPU demand only, as it does in other
OSes, but this was changed in Linux 0.99.14. This demand meseasurement reflects
OSes, but this was changed in Linux 0.99.14. This demand measurement reflects
not just the utilized resource, but also the queued demand (a saturation
measurement). Finally, the three numbers are called the "one-", "five-", and
"fifteen-minute" load averages, however these times are constants used in the
......
......@@ -9,7 +9,7 @@ to open which files. This can be useful for determining the location of config
and log files, or for troubleshooting applications that are failing, specially
on startup.
This works by tracing the open() sysscall tracepoint.
This works by tracing the open() syscall tracepoint.
Since this uses BPF, only the root user can use this tool.
.SH REQUIREMENTS
......
......@@ -18,17 +18,17 @@ CONFIG_BPF and bpftrace.
.TP
Trace CPU run queue latency system wide, printing a histogram on Ctrl-C:
#
.B runqlat
.B runqlat.bt
.SH FIELDS
.TP
1st, 2nd
This is a range of latency, in microseconds (shown in "[...)" set notation).
.TP
3rd
A column showing the count of scheduler veents in this range.
A column showing the count of scheduler events in this range.
.TP
4th
This is an ASCII histogram representing the count colimn.
This is an ASCII histogram representing the count column.
.SH OVERHEAD
This traces scheduler functions, which can become very frequent. While eBPF
has very low overhead, and this tool uses in-kernel maps for efficiency, the
......
......@@ -28,7 +28,7 @@ The run queue length is shown in the first field (after "[").
A column showing the count of samples in for that length.
.TP
4th
This is an ASCII histogram representing the count colimn.
This is an ASCII histogram representing the count column.
.SH OVERHEAD
This samples scheduler structs at 99 Hertz across all CPUs. Relatively,
this is a low rate of events, and the overhead of this tool is expected
......
......@@ -9,7 +9,7 @@ to stat which files. This can be useful for determining the location of config
and log files, or for troubleshooting applications that are failing, specially
on startup.
This traces the traecepoints for statfs(), statx(), newstat(), and
This traces the tracepoints for statfs(), statx(), newstat(), and
newlstat(). These aren't the only the stat syscalls: if you are missing
activity, you may need to add more variants.
......
......@@ -7,7 +7,7 @@ writeback.bt \- Trace file system writeback events with details. Uses bpftrace/e
This traces when file system dirtied pages are flushed to disk by kernel
writeback, and prints details including when the event occurred, and the
duration of the event. This can be useful for correlating these times with
other performace problems, and if there is a match, it would be a clue
other performance problems, and if there is a match, it would be a clue
that the problem may be caused by writeback. How quickly the kernel does
writeback can be tuned: see the kernel docs, eg,
vm.dirty_writeback_centisecs.
......
......@@ -18,7 +18,7 @@ CONFIG_BPF and bpftrace.
.TP
Trace XFS operation time, and print a summary on Ctrl-C:
#
.B xfsdist
.B xfsdist.bt
.SH FIELDS
.TP
0th
......@@ -31,7 +31,7 @@ This is a range of latency, in microseconds (shown in "[...)" set notation).
A column showing the count of operations in this range.
.TP
4th
This is an ASCII histogram representing the count colimn.
This is an ASCII histogram representing the count column.
.SH OVERHEAD
This adds low-overhead instrumentation to these XFS operations,
including reads and writes from the file system cache. Such reads and writes
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment