From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx164.postini.com [74.125.245.164]) by kanga.kvack.org (Postfix) with SMTP id B17F66B0006 for ; Thu, 7 Mar 2013 21:48:37 -0500 (EST) Received: by mail-oa0-f42.google.com with SMTP id i18so1488522oag.15 for ; Thu, 07 Mar 2013 18:48:36 -0800 (PST) Message-ID: <5139517F.60407@gmail.com> Date: Fri, 08 Mar 2013 10:48:31 +0800 From: Simon Jeons MIME-Version: 1.0 Subject: Re: [PATCH] mm: Fixup the condition whether the page cache is free References: <20130304150937.GB23767@cmpxchg.org> <51369637.6030705@gmail.com> <20130306194703.GA1953@cmpxchg.org> <5137E7F4.1060509@gmail.com> <51394945.4070803@gmail.com> <20130308023705.GI24384@cmpxchg.org> In-Reply-To: <20130308023705.GI24384@cmpxchg.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Johannes Weiner Cc: Li Haifeng , open@kvack.org, list@kvack.org, MEMORY MANAGEMENT , open list , linux-arm-kernel@lists.infradead.org On 03/08/2013 10:37 AM, Johannes Weiner wrote: > On Fri, Mar 08, 2013 at 10:13:25AM +0800, Simon Jeons wrote: >> Ping, :-) >> On 03/07/2013 09:05 AM, Simon Jeons wrote: >>> 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? > It doesn't because the pagevec holds a reference, as I wrote above. I mean since pagevec is per cpu, how can remove a concurrently freed page out of a pagevec happen? If it doesn't happen pagevec don't need to hold a reference. :-) > > Feel free to consult the code as well for questions like these ;-) -- 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: email@kvack.org