[PATCH] mm: Fixup the condition whether the page cache is free

Simon Jeons simon.jeons at gmail.com
Wed Mar 6 20:05:56 EST 2013


Hi Johannes,
On 03/07/2013 03:47 AM, Johannes Weiner wrote:
> On Wed, Mar 06, 2013 at 09:04:55AM +0800, Simon Jeons wrote:
>> Hi Johannes,
>> On 03/04/2013 11:09 PM, Johannes Weiner wrote:
>>> On Mon, Mar 04, 2013 at 09:54:26AM +0800, Li Haifeng wrote:
>>>> When a page cache is to reclaim, we should to decide whether the page
>>>> cache is free.
>>>> IMO, the condition whether a page cache is free should be 3 in page
>>>> frame reclaiming. The reason lists as below.
>>>>
>>>> When page is allocated, the page->_count is 1(code fragment is code-1 ).
>>>> And when the page is allocated for reading files from extern disk, the
>>>> page->_count will increment 1 by page_cache_get() in
>>>> add_to_page_cache_locked()(code fragment is code-2). When the page is to
>>>> reclaim, the isolated LRU list also increase the page->_count(code
>>>> fragment is code-3).
>>> The page count is initialized to 1, but that does not stay with the
>>> object.  It's a reference that is passed to the allocating task, which
>>> drops it again when it's done with the page.  I.e. the pattern is like
>>> this:
>>>
>>> instantiation:
>>> page = page_cache_alloc()	/* instantiator reference -> 1 */
>>> add_to_page_cache(page, mapping, offset)
>>>    get_page(page)		/* page cache reference -> 2 */
>>> lru_cache_add(page)
>>>    get_page(page)		/* pagevec reference -> 3 */
>>> /* ...initiate read, write, associate buffers, ... */
>>> page_cache_release(page)	/* drop instantiator reference -> 2 + private */
>>>
>>> reclaim:
>>> lru_add_drain()
>>>    page_cache_release(page)	/* drop pagevec reference -> 1 + private */
>> IIUC, when add page to lru will lead to add to pagevec firstly, and
>> pagevec will take one reference, so if lru will take over the
>> reference taken by pagevec when page transmit from pagevec to lru?
>> or just drop the reference and lru will not take reference for page?
> The LRU does not hold a reference, it would not make sense.  The
> pagevec only needs one because it would be awkward to remove a
> concurrently freed page out of a pagevec, but unlinking a page from
> the LRU is easy.  See mm/swap.c::__page_cache_release() and friends.

Since pagevec is per cpu, when can remove a concurrently freed page out 
of a pagevec happen?





More information about the linux-arm-kernel mailing list