Signed-off-by: Chris J Arges <chris.j.arges@xxxxxxxxxxxxx> --- Documentation/vm/slub.txt | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Documentation/vm/slub.txt b/Documentation/vm/slub.txt index b0c6d1b..e159c04 100644 --- a/Documentation/vm/slub.txt +++ b/Documentation/vm/slub.txt @@ -64,7 +64,7 @@ to the dentry cache with Debugging options may require the minimum possible slab order to increase as a result of storing the metadata (for example, caches with PAGE_SIZE object -sizes). This has a higher liklihood of resulting in slab allocation errors +sizes). This has a higher likelihood of resulting in slab allocation errors in low memory situations or if there's high fragmentation of memory. To switch off debugging for such caches by default, use @@ -95,7 +95,7 @@ slabinfo -a displays which slabs were merged together. Slab validation --------------- -SLUB can validate all object if the kernel was booted with slub_debug. In +SLUB can validate all objects if the kernel was booted with slub_debug. In order to do so you must have the slabinfo tool. Then you can do slabinfo -v @@ -125,7 +125,7 @@ In general slub will be able to perform this number of allocations on a slab without consulting centralized resources (list_lock) where contention may occur. -slub_min_order specifies a minim order of slabs. A similar effect like +slub_min_order specifies a minimum order of slabs. A similar effect like slub_min_objects. slub_max_order specified the order at which slub_min_objects should no @@ -133,7 +133,7 @@ longer be checked. This is useful to avoid SLUB trying to generate super large order pages to fit slub_min_objects of a slab cache with large object sizes into one high order page. Setting command line parameter debug_guardpage_minorder=N (N > 0), forces setting -slub_max_order to 0, what cause minimum possible order of slabs +slub_max_order to 0, which causes the minimum possible order of slab allocation. SLUB Debug output @@ -234,7 +234,7 @@ Padding <address> : <bytes> 3. A stackdump The stackdump describes the location where the error was detected. The cause -of the corruption is may be more likely found by looking at the function that +of the corruption may be more likely found by looking at the function that allocated or freed the object. 4. Report on how the problem was dealt with in order to ensure the continued @@ -246,7 +246,7 @@ FIX <slab cache affected>: <corrective action taken> In the above sample SLUB found that the Redzone of an active object has been overwritten. Here a string of 8 characters was written into a slab that -has the length of 8 characters. However, a 8 character string needs a +has the length of 8 characters. However, an 8 character string needs a terminating 0. That zero has overwritten the first byte of the Redzone field. After reporting the details of the issue encountered the FIX SLUB message tells us that SLUB has restored the Redzone to its proper value and then -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
