[PATCH] mm tracing: cleanup Documentation/trace/events-kmem.txt

[PATCH] mm tracing: cleanup Documentation/trace/events-kmem.txt

[Randy Dunlap]

From: Randy Dunlap <randy.dunlap@oracle.com>

Clean up typos/grammos/spellos in events-kmem.txt.

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Mel Gorman <mel@csn.ul.ie>
---
 Documentation/trace/events-kmem.txt |   14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

--- linux-2.6.32-git14.orig/Documentation/trace/events-kmem.txt
+++ linux-2.6.32-git14/Documentation/trace/events-kmem.txt
@@ -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 ther
   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 per
 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.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm tracing: cleanup Documentation/trace/events-kmem.txt

[Mel Gorman]

On Thu, Dec 17, 2009 at 12:06:44PM -0800, Randy Dunlap wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
> 
> Clean up typos/grammos/spellos in events-kmem.txt.
> 
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
> Cc: Mel Gorman <mel@csn.ul.ie>

Acked-by: Mel Gorman <mel@csn.ul.ie>

> ---
>  Documentation/trace/events-kmem.txt |   14 +++++++-------
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> --- linux-2.6.32-git14.orig/Documentation/trace/events-kmem.txt
> +++ linux-2.6.32-git14/Documentation/trace/events-kmem.txt
> @@ -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 ther
>    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 per
>  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.
> 

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>