Skip to contentSkip to conversation

mm: trivial comment cleanup in slab.c

PATCH In review Wang Sheng-Hui 2 participants 3 messages Jul 22, 2014 – Jul 25, 2014 Memory management

lore
Share & tools
lore

Wang Sheng-Hui

author
#0 lore raw

PATCH 1/1 mm: trivial comment cleanup in slab.c

Current struct kmem_cache has no 'lock' field, and slab page is managed by struct kmem_cache_node, which has 'list_lock' field.

Clean up the related comment.

Signed-off-by Wang Sheng-Hui <[email protected]>
---
 mm/slab.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)
mm/slab.c +5 -4
index 3070b92..8f7170f 100644
@@ -1724,7 +1724,8 @@ slab_out_of_memory(struct kmem_cache *cachep, gfp_t gfpflags, int nodeid)
 }
 
 /*
- * Interface to system's page allocator. No need to hold the cache-lock.
+ * Interface to system's page allocator. No need to hold the
+ * kmem_cache_node ->list_lock.
  *
  * If we requested dmaable memory, we will get it. Even if we
  * did not request dmaable memory, we might get it, but that

@@ -2026,9 +2027,9 @@ static void slab_destroy_debugcheck(struct kmem_cache *cachep,
  * @cachep: cache pointer being destroyed
  * @page: page pointer being destroyed
  *
- * Destroy all the objs in a slab, and release the mem back to the system.
- * Before calling the slab must have been unlinked from the cache.  The
- * cache-lock is not held/needed.
+ * Destroy all the objs in a slab page, and release the mem back to the system.
+ * Before calling the slab page must have been unlinked from the cache. The
+ * kmem_cache_node ->list_lock is not held/needed.
  */
 static void slab_destroy(struct kmem_cache *cachep, struct page *page)
 {
Signature · 7 lines
1.8.3.2

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
#1 lore raw
Quoted 6 lines · Wang Sheng-Hui

Current struct kmem_cache has no 'lock' field, and slab page is managed by struct kmem_cache_node, which has 'list_lock' field.

Clean up the related comment.

I think this is fine, but not sure if the s/slab/slab page/ change makes anything clearer and is unmentioned in the changelog.

Quoted 22 lines
Signed-off-by Wang Sheng-Hui <[email protected]>
---
 mm/slab.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)
mm/slab.c +2 -1
index 3070b92..8f7170f 100644
@@ -1724,7 +1724,8 @@ slab_out_of_memory(struct kmem_cache *cachep, gfp_t gfpflags, int nodeid)
 }
 
 /*
- * Interface to system's page allocator. No need to hold the cache-lock.
+ * Interface to system's page allocator. No need to hold the
+ * kmem_cache_node ->list_lock.
  *
  * If we requested dmaable memory, we will get it. Even if we
  * did not request dmaable memory, we might get it, but that

@@ -2026,9 +2027,9 @@ static void slab_destroy_debugcheck(struct kmem_cache *cachep,
  * @cachep: cache pointer being destroyed
  * @page: page pointer being destroyed

mm/slab.c static void slab_destroy_debugcheck(struct kmem_cache *cachep, · line 2035

Quoted 10 lines
mm/slab.c +3 -3
  *
- * Destroy all the objs in a slab, and release the mem back to the system.
- * Before calling the slab must have been unlinked from the cache.  The
- * cache-lock is not held/needed.
+ * Destroy all the objs in a slab page, and release the mem back to the system.
+ * Before calling the slab page must have been unlinked from the cache. The
+ * kmem_cache_node ->list_lock is not held/needed.
  */
 static void slab_destroy(struct kmem_cache *cachep, struct page *page)
 {

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

author
#2 lore raw
Quoted 12 lines · David Rientjes
Quoted 6 lines · Wang Sheng-Hui

Current struct kmem_cache has no 'lock' field, and slab page is managed by struct kmem_cache_node, which has 'list_lock' field.

Clean up the related comment.

I think this is fine, but not sure if the s/slab/slab page/ change makes anything clearer and is unmentioned in the changelog.

David,

I used "slab page" to mention the pages used for slab. Hope that won't introduce any confusion/misunderstanding.

Regards,
Sheng-Hui

Quoted 24 lines
Quoted 24 lines
Signed-off-by Wang Sheng-Hui <[email protected]>
---
 mm/slab.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)
mm/slab.c +2 -2
index 3070b92..8f7170f 100644
@@ -1724,7 +1724,8 @@ slab_out_of_memory(struct kmem_cache *cachep, gfp_t gfpflags, int nodeid)
 }
 
 /*
- * Interface to system's page allocator. No need to hold the cache-lock.
+ * Interface to system's page allocator. No need to hold the
+ * kmem_cache_node ->list_lock.
  *
  * If we requested dmaable memory, we will get it. Even if we
  * did not request dmaable memory, we might get it, but that

@@ -2026,9 +2027,9 @@ static void slab_destroy_debugcheck(struct kmem_cache *cachep,
  * @cachep: cache pointer being destroyed
  * @page: page pointer being destroyed
  *
- * Destroy all the objs in a slab, and release the mem back to the system.
Quoted 8 lines

mm/slab.c static void slab_destroy_debugcheck(struct kmem_cache *cachep, · line 2035

Quoted 8 lines
mm/slab.c +3 -2
- * Before calling the slab must have been unlinked from the cache.  The
- * cache-lock is not held/needed.
+ * Destroy all the objs in a slab page, and release the mem back to the system.
+ * Before calling the slab page must have been unlinked from the cache. The
+ * kmem_cache_node ->list_lock is not held/needed.
  */
 static void slab_destroy(struct kmem_cache *cachep, struct page *page)
 {

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