在一次偶然的机会，在研究如何降低pagecache占用的过程中，走查了 invalidate_mapping_pages的代码：
通过调用 __pagevec_lookup 在radix树中收集一部分page，然后尝试调用 invalidate_inode_page 来释放这个page。
我主要看__pagevec_lookup 对引用计数的修改：
__pagevec_lookup -- >__find_get_pages -->page_cache_get_speculative
static inline int page_cache_get_speculative(struct page *page)
{/*³¢ÊÔÔö¼ÓÒýÓüÆÊý£¬Èç¹ûpage²»ÎªfreeµÄ»°*/
VM_BUG_ON(in_interrupt()); #ifdef CONFIG_TINY_RCU
# ifdef CONFIG_PREEMPT_COUNT
VM_BUG_ON(!in_atomic());
# endif
/*
* Preempt must be disabled here - we rely on rcu_read_lock doing
* this for us.
*
* Pagecache won't be truncated from interrupt context, so if we have
* found a page in the radix tree here, we have pinned its refcount by
* disabling preempt, and hence no need for the "speculative get" that
* SMP requires.
*/
VM_BUG_ON_PAGE(page_count(page) == , page);
page_ref_inc(page); #else
if (unlikely(!get_page_unless_zero(page))) {-------------走这个分支
/*
* Either the page has been freed, or will be freed.
* In either case, retry here and the caller should
* do the right thing (see comments above).
*/
return ;
}
#endif
VM_BUG_ON_PAGE(PageTail(page), page); return ;
}
static inline int get_page_unless_zero(struct page *page)
{
return page_ref_add_unless(page, 1, 0);
}
static inline int page_ref_add_unless(struct page *page, int nr, int u)
{
return atomic_add_unless(&page->_count, nr, u);
}
/**
* atomic_add_unless - add unless the number is already a given value
* @v: pointer of type atomic_t
* @a: the amount to add to v...
* @u: ...unless v is equal to u.
*
* Atomically adds @a to @v, so long as @v was not already @u.
* Returns non-zero if @v was not @u, and zero otherwise.
*/
static inline int atomic_add_unless(atomic_t *v, int a, int u)
{
return __atomic_add_unless(v, a, u) != u;
}
最后一个函数注释很明白，除非 page->_count 的计数为1，否则不增加引用计数，也就是说，当原值 page->_count 为1的时候，增加到2，然后返回。
然后看释放过程：
if (!trylock_page(page))
continue;
WARN_ON(page->index != index);
ret = invalidate_inode_page(page);
unlock_page(page);
主要的调用链为:
invalidate_inode_page--> invalidate_complete_page --> remove_mapping --> __remove_mapping
/*
* Same as remove_mapping, but if the page is removed from the mapping, it
* gets returned with a refcount of 0.
*/
static int __remove_mapping(struct address_space *mapping, struct page *page,
bool reclaimed)
{
BUG_ON(!PageLocked(page));
BUG_ON(mapping != page_mapping(page)); spin_lock_irq(&mapping->tree_lock);
/*
* The non racy check for a busy page.
*
* Must be careful with the order of the tests. When someone has
* a ref to the page, it may be possible that they dirty it then
* drop the reference. So if PageDirty is tested before page_count
* here, then the following race may occur:
*
* get_user_pages(&page);
* [user mapping goes away]
* write_to(page);
* !PageDirty(page) [good]
* SetPageDirty(page);
* put_page(page);
* !page_count(page) [good, discard it]
*
* [oops, our write_to data is lost]
*
* Reversing the order of the tests ensures such a situation cannot
* escape unnoticed. The smp_rmb is needed to ensure the page->flags
* load is not satisfied before that of page->_count.
*
* Note that if SetPageDirty is always performed via set_page_dirty,
* and thus under tree_lock, then this ordering is not required.
*/
if (!page_ref_freeze(page, ))
goto cannot_free;
/* note: atomic_cmpxchg in page_freeze_refs provides the smp_rmb */
if (unlikely(PageDirty(page))) {
page_ref_unfreeze(page, );
goto cannot_free;
} if (PageSwapCache(page)) {
swp_entry_t swap = { .val = page_private(page) };
__delete_from_swap_cache(page);
spin_unlock_irq(&mapping->tree_lock);
swapcache_free(swap, page);
} else {
void (*freepage)(struct page *);
void *shadow = NULL; freepage = mapping->a_ops->freepage;
/*
* Remember a shadow entry for reclaimed file cache in
* order to detect refaults, thus thrashing, later on.
*
* But don't store shadows in an address space that is
* already exiting. This is not just an optizimation,
* inode reclaim needs to empty out the radix tree or
* the nodes are lost. Don't plant shadows behind its
* back.
*
* We also don't store shadows for DAX mappings because the
* only page cache pages found in these are zero pages
* covering holes, and because we don't want to mix DAX
* exceptional entries and shadow exceptional entries in the
* same page_tree.
*/
if (reclaimed && page_is_file_cache(page) &&
!mapping_exiting(mapping) && !dax_mapping(mapping))
shadow = workingset_eviction(mapping, page);
__delete_from_page_cache(page, shadow);
spin_unlock_irq(&mapping->tree_lock);
mem_cgroup_uncharge_cache_page(page); if (freepage != NULL)
freepage(page);
} return ; cannot_free:
spin_unlock_irq(&mapping->tree_lock);
return ;
}
看第一行的注释，我们可以知道，remove_mapping 是__remove_mapping的包裹函数， __remove_mapping函数如果将页面从page cache中移除成功，则会将page的引用计数 返回0.
我们关注最关键的一段：
if (!page_ref_freeze(page, ))
goto cannot_free; static inline int page_ref_freeze(struct page *page, int count)
{
return likely(atomic_cmpxchg(&page->_count, count, ) == count);
}
atomic_cmpxchg函数实现了一个比较+交换的原子操作(原子就是说cpu要不就不
做，要做就一定要做完，不会存在中间状态,对应这里就是比较和交换要一次过做完).
关于atomic 和比较交换的一些函数，网上资料较多，在此不赘述，总体的意思就是，当page的count为2，则交换为0，并且返回旧值2，
也就是 page->_count 为2的话，则可以释放，否则 会走 cannot_free 的分支。因为之前 __pagevec_lookup 执行后，page->_count肯定为2，所以能最终free。
回到 包裹函数 remove_mapping
/*
* Attempt to detach a locked page from its ->mapping. If it is dirty or if
* someone else has a ref on the page, abort and return 0. If it was
* successfully detached, return 1. Assumes the caller has a single ref on
* this page.
*/
int remove_mapping(struct address_space *mapping, struct page *page)
{
if (__remove_mapping(mapping, page, false)) {
/*
* Unfreezing the refcount with 1 rather than 2 effectively
* drops the pagecache ref for us without requiring another
* atomic operation.
*/
page_ref_unfreeze(page, );
return ;
}
return ;
}
因为在lookup阶段，将原有的因为计数page->_count为1的，增加到2，然后通过一个交换判断，如果是2的，则交换为0，然后最终调用 page_ref_unfreeze 将引用计数设置为1，
释放成功。有兴趣的同学可以继续一下，因为在pagecache中的页，默认是加入到lru的，为了防止频繁地加入到lru，又设计了一个pagevec数组，当数组满了或者主动调用drain函数来将
数组中缓存的page 刷入到lru链表中，为了区分这两种状态，加入到lru的pagevec数组的page，计数要加1，当真正加入到lru中的时候，计数又减1，恢复到之前的计数值。所以lru并不占用计数。
我们知道，页面从freelist中分配出来的时候，引用计数是需要加1的。
get_page_from_freelist->buffered_rmqueue->prep_new_page->set_page_refcounted，由此函数完成+1.
写本文的原因是，我原来以为的加入到lru，加入到radix树，都需要增加引用计数的，在加入radix树，确实是加1了，但一般出来之后就会-1，所以在radix树的时候，计数增加只是临时行为，lru也是如此，因为加入到lru，我只看到了加入到lru的pagevec数组，这个时候确实是+1了，但是
当真正加入到lru链表的时候，又减了1，也就是page真正加入到lru链表，会保持计数不变，当然PG_Lru肯定是要置位的。
同理，我在看函数 add_to_page_cache_lru 的时候，确实对加入的page 增加了引用计数，所以一直认为pagecache中的页的引用计数至少是2， 调用 __pagevec_lookup 后应该为3，
当我看到 如下代码之后，就死活不理解。
if (!page_ref_freeze(page, 2))
goto cannot_free;
然后回过头再去看单凡是调用add_to_page_cache_lru 之后，都会调用put_page，不管成功失败，如果成功，相当于加入pagecache成功，对应的put_page就是减去对加入的时候的page的引用计数，那么此时计数为1，如果加入失败，那么对应的put_page就是释放内存，因为此时计数为0.
回到文章的开头，如果一个页面，没人访问，在pagecache中，当然也在lru链表中的时候，引用计数为1，而这个1，还是从freelist中摘除的时候来增加的。也有可能为2，此时说明没有在lru中，只在pagevec中，
如果一个页面，没人访问，在pagecache中，但是处于lru的lruvec中，此时的引用计数应该为2，所以才会有在调用fadvise64_64 的时候，
case POSIX_FADV_DONTNEED:
if (!bdi_write_congested(mapping->backing_dev_info))
__filemap_fdatawrite_range(mapping, offset, endbyte,
WB_SYNC_NONE); /* First and last FULL page! */
start_index = (offset+(PAGE_CACHE_SIZE-)) >> PAGE_CACHE_SHIFT;
end_index = (endbyte >> PAGE_CACHE_SHIFT); if (end_index >= start_index) {
unsigned long count = invalidate_mapping_pages(mapping,
start_index, end_index); /*
* If fewer pages were invalidated than expected then
* it is possible that some of the pages were on
* a per-cpu pagevec for a remote CPU. Drain all
* pagevecs and try again.
*/
if (count < (end_index - start_index + )) {
lru_add_drain_all();
invalidate_mapping_pages(mapping, start_index,
end_index);
}
}
break;
当发现释放的页面小于请求的页面数，会调用 lru_add_drain_all ，如果不调用这个，则有可能因为处于lru的pagevec的页无法释放，其实有大概率是能够释放的。
当时的stap记录如下：
调用 page_cache_get_speculative 之前的计数，为1，此时就是出于pagecache中的页的原本计数，（排除其他正在使用的页）
enter 1147=page=0xffffea000e955080,flags=0x6fffff00020068,mapcount=-1,_count=1===
0xffffffff81183381 : __find_get_pages+0x81/0x170 [kernel]
0xffffffff8118ff2e : __pagevec_lookup+0x1e/0x30 [kernel]
0xffffffff81191243 : invalidate_mapping_pages+0x93/0x1f0 [kernel]
0xffffffff811850b4 : SyS_fadvise64_64+0x1a4/0x290 [kernel]
0xffffffff811851ae : SyS_fadvise64+0xe/0x10 [kernel]
0xffffffff81698b09 : system_call_fastpath+0x16/0x1b [kernel]
调用 page_cache_get_speculative之后的计数，为2，
enter 1163=page=0xffffea000e955080,flags=0x6fffff00020068,mapcount=-1,_count=2===
0xffffffff811833b5 : __find_get_pages+0xb5/0x170 [kernel]
0xffffffff8118ff2e : __pagevec_lookup+0x1e/0x30 [kernel]
0xffffffff81191243 : invalidate_mapping_pages+0x93/0x1f0 [kernel]
0xffffffff811850b4 : SyS_fadvise64_64+0x1a4/0x290 [kernel]
0xffffffff811851ae : SyS_fadvise64+0xe/0x10 [kernel]
0xffffffff81698b09 : system_call_fastpath+0x16/0x1b [kernel]
有一个同事问到，在__generic_file_splice_read 函数中，有一个while循环
while (spd.nr_pages < nr_pages) {
/*
* Page could be there, find_get_pages_contig() breaks on
* the first hole.
*/
page = find_get_page(mapping, index);//找具体的page，之前连续的时候没找到的
if (!page) {//经过预读仍然没找到
/*
* page didn't exist, allocate one.
*/
page = page_cache_alloc_cold(mapping);//分配页面
if (!page)
break;
//加入到radix树，主要有修改page的mapping等
error = add_to_page_cache_lru(page, mapping, index,
GFP_KERNEL);
if (unlikely(error)) {
page_cache_release(page);
if (error == -EEXIST)
continue;
break;
}
/*
* add_to_page_cache() locks the page, unlock it
* to avoid convoluting the logic below even more.
*/
unlock_page(page);
}
spd.pages[spd.nr_pages++] = page;//将找到的或者分配的页面加入到spd
index++;
}
经过page_cache_alloc_cold 再加入到 add_to_page_cache_lru 的页面，并没有-1啊，岂不是跟之前的描述矛盾，这个地方没有减1，其实是因为这个计数本就应该为2，因为这个page加入到了spd中，计数必须增加，既然-1又需要加1，干脆就不动，前面通过 find_get_pages_contig 加入到spd中的页，此时计数应该也是2,（排查并发操作的情况，否则就是>2）.
经过 find_get_pages_contig 加入到spd，或者通过 spd.pages[spd.nr_pages++] = page;//将找到的或者分配的页面加入到spd
保证了此时在spd中的page的计数都至少为2.这个在spd进行release的时候，统一进行-1，计数又恢复了。
所以说，pagecache中的且位于lru链表的page，在没有读写，也没有kswap正在对该page进行老化的情况下，引用计数就是1。