|author||Randy Dunlap <email@example.com>||2009-12-21 14:37:23 -0800|
|committer||Linus Torvalds <firstname.lastname@example.org>||2009-12-22 14:17:55 -0800|
mm tracing: cleanup Documentation/trace/events-kmem.txt
Clean up typos/grammos/spellos in events-kmem.txt. Signed-off-by: Randy Dunlap <email@example.com> Cc: Mel Gorman <firstname.lastname@example.org> Signed-off-by: Andrew Morton <email@example.com> Signed-off-by: Linus Torvalds <firstname.lastname@example.org>
Diffstat (limited to 'Documentation/trace/events-kmem.txt')
1 files changed, 7 insertions, 7 deletions
diff --git a/Documentation/trace/events-kmem.txt b/Documentation/trace/events-kmem.txt
index 6ef2a8652e17..aa82ee4a5a87 100644
@@ -1,7 +1,7 @@
Subsystem Trace Points: kmem
-The tracing system kmem captures events related to object and page allocation
-within the kernel. Broadly speaking there are four major subheadings.
+The kmem tracing system captures events related to object and page allocation
+within the kernel. Broadly speaking there are five major subheadings.
o Slab allocation of small objects of unknown type (kmalloc)
o Slab allocation of small objects of known type
@@ -9,7 +9,7 @@ within the kernel. Broadly speaking there are four major subheadings.
o Per-CPU Allocator Activity
o External Fragmentation
-This document will describe what each of the tracepoints are and why they
+This document describes what each of the tracepoints is and why they
might be useful.
1. Slab allocation of small objects of unknown type
@@ -34,7 +34,7 @@ kmem_cache_free call_site=%lx ptr=%p
These events are similar in usage to the kmalloc-related events except that
it is likely easier to pin the event down to a specific cache. At the time
of writing, no information is available on what slab is being allocated from,
-but the call_site can usually be used to extrapolate that information
+but the call_site can usually be used to extrapolate that information.
3. Page allocation
@@ -80,9 +80,9 @@ event indicating whether it is for a percpu_refill or not.
When the per-CPU list is too full, a number of pages are freed, each one
which triggers a mm_page_pcpu_drain event.
-The individual nature of the events are so that pages can be tracked
+The individual nature of the events is so that pages can be tracked
between allocation and freeing. A number of drain or refill pages that occur
-consecutively imply the zone->lock being taken once. Large amounts of PCP
+consecutively imply the zone->lock being taken once. Large amounts of per-CPU
refills and drains could imply an imbalance between CPUs where too much work
is being concentrated in one place. It could also indicate that the per-CPU
lists should be a larger size. Finally, large amounts of refills on one CPU
@@ -102,6 +102,6 @@ is important.
Large numbers of this event implies that memory is fragmenting and
high-order allocations will start failing at some time in the future. One
-means of reducing the occurange of this event is to increase the size of
+means of reducing the occurrence of this event is to increase the size of
min_free_kbytes in increments of 3*pageblock_size*nr_online_nodes where
pageblock_size is usually the size of the default hugepage size.