From: Wang Sheng-Hui <shhuiw@gmail.com>
To: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org
Subject: Re: [PATCH] mm: trivial comment cleanup in slab.c
Date: Fri, 25 Jul 2014 08:51:08 +0800 [thread overview]
Message-ID: <53D1A9FC.7090202@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1407221457010.5814@chino.kir.corp.google.com>
On 2014a1'07ae??23ae?JPY 05:57, David Rientjes wrote:
> On Tue, 22 Jul 2014, Wang Sheng-Hui wrote:
>
>>
>> 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
>> Signed-off-by: Wang Sheng-Hui <shhuiw@gmail.com>
>> ---
>> mm/slab.c | 9 +++++----
>> 1 file changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/mm/slab.c b/mm/slab.c
>> index 3070b92..8f7170f 100644
>> --- a/mm/slab.c
>> +++ b/mm/slab.c
>> @@ -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)
>> {
--
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>
prev parent reply other threads:[~2014-07-25 0:51 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-22 7:24 [PATCH] mm: trivial comment cleanup in slab.c Wang Sheng-Hui
2014-07-22 21:57 ` David Rientjes
2014-07-25 0:51 ` Wang Sheng-Hui [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53D1A9FC.7090202@gmail.com \
--to=shhuiw@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.