[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87d1qs9lah.fsf@linux.vnet.ibm.com>
Date: Fri, 18 Mar 2016 15:10:06 +0530
From: "Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
To: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Hugh Dickins <hughd@...gle.com>,
Andrea Arcangeli <aarcange@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>
Cc: Dave Hansen <dave.hansen@...el.com>,
Vlastimil Babka <vbabka@...e.cz>,
Christoph Lameter <cl@...two.org>,
Naoya Horiguchi <n-horiguchi@...jp.nec.com>,
Jerome Marchand <jmarchan@...hat.com>,
Yang Shi <yang.shi@...aro.org>,
Sasha Levin <sasha.levin@...cle.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
linux-fsdevel@...r.kernel.org,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
Subject: Re: [PATCHv4 04/25] rmap: support file thp
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com> writes:
> [ text/plain ]
> Naive approach: on mapping/unmapping the page as compound we update
> ->_mapcount on each 4k page. That's not efficient, but it's not obvious
> how we can optimize this. We can look into optimization later.
>
> PG_double_map optimization doesn't work for file pages since lifecycle
> of file pages is different comparing to anon pages: file page can be
> mapped again at any time.
>
Can you explain this more ?. We added PG_double_map so that we can keep
page_remove_rmap simpler. So if it isn't a compound page we still can do
if (!atomic_add_negative(-1, &page->_mapcount))
I am trying to understand why we can't use that with file pages ?
-aneesh
Powered by blists - more mailing lists