kmem: add slab-specific documentation about the kmem controller
authorGlauber Costa <>
Tue, 18 Dec 2012 22:23:08 +0000 (14:23 -0800)
committerLinus Torvalds <>
Tue, 18 Dec 2012 23:02:15 +0000 (15:02 -0800)
Signed-off-by: Glauber Costa <>
Cc: Christoph Lameter <>
Cc: David Rientjes <>
Cc: Frederic Weisbecker <>
Cc: Greg Thelen <>
Cc: Johannes Weiner <>
Cc: JoonSoo Kim <>
Cc: KAMEZAWA Hiroyuki <>
Cc: Mel Gorman <>
Cc: Michal Hocko <>
Cc: Pekka Enberg <>
Cc: Rik van Riel <>
Cc: Suleiman Souhlal <>
Cc: Tejun Heo <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>

index 5b5b631437789018758bdde63a5db6689cb7164e..8b8c28b9864c58f4c23ac199036fc260fc32cd6f 100644 (file)
@@ -301,6 +301,13 @@ to trigger slab reclaim when those limits are reached.
 kernel memory, we prevent new processes from being created when the kernel
 memory usage is too high.
+* slab pages: pages allocated by the SLAB or SLUB allocator are tracked. A copy
+of each kmem_cache is created everytime the cache is touched by the first time
+from inside the memcg. The creation is done lazily, so some objects can still be
+skipped while the cache is being created. All objects in a slab page should
+belong to the same memcg. This only fails to hold when a task is migrated to a
+different memcg during the page allocation by the cache.
 * sockets memory pressure: some sockets protocols have memory pressure
 thresholds. The Memory Controller allows them to be controlled individually
 per cgroup, instead of globally.