From: Vlastimil Babka <vbabka@suse.cz>
To: Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>
Cc: Hugh Dickins <hughd@google.com>,
Johannes Berg <johannes@sipsolutions.net>,
"David S. Miller" <davem@davemloft.net>,
Sunil Goutham <sgoutham@cavium.com>,
Chris Metcalf <cmetcalf@mellanox.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] mm: rename _count, field of the struct page, to _refcount
Date: Wed, 30 Mar 2016 10:29:42 +0200 [thread overview]
Message-ID: <56FB8E76.50005@suse.cz> (raw)
In-Reply-To: <20160330082701.GG1678@js1304-P5Q-DELUXE>
On 03/30/2016 10:27 AM, Joonsoo Kim wrote:
> On Tue, Mar 29, 2016 at 12:23:13PM -0700, Andrew Morton wrote:
>> On Tue, 29 Mar 2016 11:27:47 +0200 Vlastimil Babka <vbabka@suse.cz> wrote:
>>
>>>> v2: change more _count usages to _refcount
>>>
>>> There's also
>>> Documentation/vm/transhuge.txt talking about ->_count
>>> include/linux/mm.h: * requires to already have an elevated page->_count.
>>> include/linux/mm_types.h: * Keep _count separate from slub cmpxchg_double data.
>>> include/linux/mm_types.h: * slab_lock but _count is not.
>>> include/linux/pagemap.h: * If the page is free (_count == 0), then _count is untouched, and 0
>>> include/linux/pagemap.h: * is returned. Otherwise, _count is incremented by 1 and 1 is returned.
>>> include/linux/pagemap.h: * this allows allocators to use a synchronize_rcu() to stabilize _count.
>>> include/linux/pagemap.h: * Remove-side that cares about stability of _count (eg. reclaim) has the
>>> mm/huge_memory.c: * tail_page->_count is zero and not changing from under us. But
>>> mm/huge_memory.c: /* Prevent deferred_split_scan() touching ->_count */
>>> mm/internal.h: * Turn a non-refcounted page (->_count == 0) into refcounted with
>>> mm/page_alloc.c: bad_reason = "nonzero _count";
>>> mm/page_alloc.c: bad_reason = "nonzero _count";
>>> mm/page_alloc.c: * because their page->_count is zero at all time.
>>> mm/slub.c: * as page->_count. If we assign to ->counters directly
>>> mm/slub.c: * we run the risk of losing updates to page->_count, so
>>> mm/vmscan.c: * load is not satisfied before that of page->_count.
>>> mm/vmscan.c: * The downside is that we have to touch page->_count against each page.
>>>
>>> I've arrived at the following command to find this:
>>> git grep "[^a-zA-Z0-9_]_count[^_]"
>>>
>>> Not that many false positives in the output :)
>>
>>
>> From: Andrew Morton <akpm@linux-foundation.org>
>> Subject: mm-rename-_count-field-of-the-struct-page-to-_refcount-fix
>>
>> fix comments, per Vlastimil
>
> Andrew and Vlastimil, great thanks!
Thanks, Andrew.
That leaves just Documentation/vm/transhuge.txt to you, Joonsoo :)
> Thanks.
>
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Vlastimil Babka <vbabka@suse.cz>
To: Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>
Cc: Hugh Dickins <hughd@google.com>,
Johannes Berg <johannes@sipsolutions.net>,
"David S. Miller" <davem@davemloft.net>,
Sunil Goutham <sgoutham@cavium.com>,
Chris Metcalf <cmetcalf@mellanox.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] mm: rename _count, field of the struct page, to _refcount
Date: Wed, 30 Mar 2016 10:29:42 +0200 [thread overview]
Message-ID: <56FB8E76.50005@suse.cz> (raw)
In-Reply-To: <20160330082701.GG1678@js1304-P5Q-DELUXE>
On 03/30/2016 10:27 AM, Joonsoo Kim wrote:
> On Tue, Mar 29, 2016 at 12:23:13PM -0700, Andrew Morton wrote:
>> On Tue, 29 Mar 2016 11:27:47 +0200 Vlastimil Babka <vbabka@suse.cz> wrote:
>>
>>>> v2: change more _count usages to _refcount
>>>
>>> There's also
>>> Documentation/vm/transhuge.txt talking about ->_count
>>> include/linux/mm.h: * requires to already have an elevated page->_count.
>>> include/linux/mm_types.h: * Keep _count separate from slub cmpxchg_double data.
>>> include/linux/mm_types.h: * slab_lock but _count is not.
>>> include/linux/pagemap.h: * If the page is free (_count == 0), then _count is untouched, and 0
>>> include/linux/pagemap.h: * is returned. Otherwise, _count is incremented by 1 and 1 is returned.
>>> include/linux/pagemap.h: * this allows allocators to use a synchronize_rcu() to stabilize _count.
>>> include/linux/pagemap.h: * Remove-side that cares about stability of _count (eg. reclaim) has the
>>> mm/huge_memory.c: * tail_page->_count is zero and not changing from under us. But
>>> mm/huge_memory.c: /* Prevent deferred_split_scan() touching ->_count */
>>> mm/internal.h: * Turn a non-refcounted page (->_count == 0) into refcounted with
>>> mm/page_alloc.c: bad_reason = "nonzero _count";
>>> mm/page_alloc.c: bad_reason = "nonzero _count";
>>> mm/page_alloc.c: * because their page->_count is zero at all time.
>>> mm/slub.c: * as page->_count. If we assign to ->counters directly
>>> mm/slub.c: * we run the risk of losing updates to page->_count, so
>>> mm/vmscan.c: * load is not satisfied before that of page->_count.
>>> mm/vmscan.c: * The downside is that we have to touch page->_count against each page.
>>>
>>> I've arrived at the following command to find this:
>>> git grep "[^a-zA-Z0-9_]_count[^_]"
>>>
>>> Not that many false positives in the output :)
>>
>>
>> From: Andrew Morton <akpm@linux-foundation.org>
>> Subject: mm-rename-_count-field-of-the-struct-page-to-_refcount-fix
>>
>> fix comments, per Vlastimil
>
> Andrew and Vlastimil, great thanks!
Thanks, Andrew.
That leaves just Documentation/vm/transhuge.txt to you, Joonsoo :)
> Thanks.
>
next prev parent reply other threads:[~2016-03-30 8:29 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-28 6:30 [PATCH v2 1/2] mm/page_ref: use page_ref helper instead of direct modification of _count js1304
2016-03-28 6:30 ` js1304
2016-03-28 6:30 ` [PATCH v2 2/2] mm: rename _count, field of the struct page, to _refcount js1304
2016-03-28 6:30 ` js1304
2016-03-29 9:27 ` Vlastimil Babka
2016-03-29 9:27 ` Vlastimil Babka
2016-03-29 19:23 ` Andrew Morton
2016-03-29 19:23 ` Andrew Morton
2016-03-30 8:27 ` Joonsoo Kim
2016-03-30 8:27 ` Joonsoo Kim
2016-03-30 8:29 ` Vlastimil Babka [this message]
2016-03-30 8:29 ` Vlastimil Babka
2016-03-29 9:12 ` [PATCH v2 1/2] mm/page_ref: use page_ref helper instead of direct modification of _count Vlastimil Babka
2016-03-29 9:12 ` Vlastimil Babka
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=56FB8E76.50005@suse.cz \
--to=vbabka@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=cmetcalf@mellanox.com \
--cc=davem@davemloft.net \
--cc=hughd@google.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=sgoutham@cavium.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.