page cache问题

embeddedlwp

回复 119# firkraag


http://bbs.chinaunix.net/forum.p ... id%3D433&page=2

17楼有瀚海书香的回复，但是我不确定！

   

firkraag

回复 118# embeddedlwp
不是匿名页->是file map页->发生wp falult->是private map->变成anon map->增加anon,减少file。

   

firkraag

回复 121# embeddedlwp

这个大概和你的应用相关，很可能有很多页被换出。比如3倍内存的页都被换出（被换出的页没被换入，使用它从前占用的page的页又被换出，当然这很极端）。至于那个2倍，我觉得是个一般情况下的经验值。不管怎么说，还是读写内存要比换进换出快的多，美刀多的话，还是加内存吧，交换区是穷人变通啊。

   

embeddedlwp

回复 122# firkraag


不是匿名页->是file map页->发生wp falult->是private map->变成anon map->增加anon,减少file。

===============================

http://lxr.linux.no/linux+v2.6.24/mm/memory.c#L1545

有点晕了，我可以理解是file map页->发生wp falult->是private map，从链接给出的代码看“变成anon map”怎么做到的？


   

firkraag

回复 124# embeddedlwp

对private file map的页进行写操作会导致该页变成anon map,在判断的上几句，不是刚刚分配了一个页，并将旧页内容copy过去吗，然后不就是写pte，将该页加入anon map的操作了。

   

embeddedlwp

回复 125# firkraag


if (!PageAnon(old_page)) {
1642                                dec_mm_counter(mm, file_rss);
1643                                inc_mm_counter(mm, anon_rss);
1644                        }

这里为什么要递减file_rss呢？

一个page是parent的且是private的，此时发生COW，那么直接多了一个anon page，递增anon_rss就可以啊，




   

firkraag

回复 126# embeddedlwp
oldpage不是file map的吗，新页顶替了它变成了anon map,不就是该进程的file map page数减1，anon map增1吗。

   

embeddedlwp

回复 127# firkraag


恩，看了一下在dup_mm函数中，复制父进程的mm，由于这个file_rss计数是mm的一个字段，所以也被复制过来。

   

embeddedlwp

回复 127# firkraag


try_to_unuse函数中的问题

但是可能强迫try_to_unuse()对交换区引用计数器的swap_map数组扫描几次。这是因为
对交换出页引用的线性区可能在一次扫描中消失，而在随后又出现在进程链表中。
例如，回想do_munmap()函数的描述：只要进程释放一个线性地址区间，do_munmap()就从
进程链表中删除所有受影响线性地址所在的线性区；随后，该函数把只是部分解除映射的
那部分线性区重新插入进程链表中。

==================================


ULK3上这段怎么理解呢？跟删除的线性地址区间无关的部分，do_munmap函数会调用
split_vma()函数将其分离，怎么还会产生“部分解除映射的
那部分线性区”
   

embeddedlwp

回复 127# firkraag

try_to_unuse这部分：

/*
                 * Wait for and lock page.  When do_swap_page races with
                 * try_to_unuse, do_swap_page can handle the fault much
                 * faster than try_to_unuse can locate the entry.  This
                 * apparently redundant "wait_on_page_locked" lets try_to_unuse
                 * defer to do_swap_page in such a case - in some tests,
                 * do_swap_page and try_to_unuse repeatedly compete.
                 */
                wait_on_page_locked(page);
                wait_on_page_writeback(page);
                lock_page(page);
                wait_on_page_writeback(page);

为什么把page lock了，还等在writeback，不是上边刚等完吗？