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 <[email protected]> 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 <[email protected]>
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.
