Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753511AbbEROcb (ORCPT ); Mon, 18 May 2015 10:32:31 -0400 Received: from cantor2.suse.de ([195.135.220.15]:48768 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752277AbbEROc0 (ORCPT ); Mon, 18 May 2015 10:32:26 -0400 Message-ID: <5559F7F6.7060801@suse.cz> Date: Mon, 18 May 2015 16:32:22 +0200 From: Vlastimil Babka User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Kirill A. Shutemov" , Andrew Morton , Andrea Arcangeli , Hugh Dickins CC: Dave Hansen , Mel Gorman , Rik van Riel , Christoph Lameter , Naoya Horiguchi , Steve Capper , "Aneesh Kumar K.V" , Johannes Weiner , Michal Hocko , Jerome Marchand , Sasha Levin , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCHv5 19/28] mm: store mapcount for compound page separately References: <1429823043-157133-1-git-send-email-kirill.shutemov@linux.intel.com> <1429823043-157133-20-git-send-email-kirill.shutemov@linux.intel.com> In-Reply-To: <1429823043-157133-20-git-send-email-kirill.shutemov@linux.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3218 Lines: 86 On 04/23/2015 11:03 PM, Kirill A. Shutemov wrote: > We're going to allow mapping of individual 4k pages of THP compound and > we need a cheap way to find out how many time the compound page is > mapped with PMD -- compound_mapcount() does this. > > We use the same approach as with compound page destructor and compound > order: use space in first tail page, ->mapping this time. > > page_mapcount() counts both: PTE and PMD mappings of the page. > > Signed-off-by: Kirill A. Shutemov > Tested-by: Sasha Levin > --- > include/linux/mm.h | 25 ++++++++++++-- > include/linux/mm_types.h | 1 + > include/linux/rmap.h | 4 +-- > mm/debug.c | 5 ++- > mm/huge_memory.c | 2 +- > mm/hugetlb.c | 4 +-- > mm/memory.c | 2 +- > mm/migrate.c | 2 +- > mm/page_alloc.c | 14 ++++++-- > mm/rmap.c | 87 +++++++++++++++++++++++++++++++++++++----------- > 10 files changed, 114 insertions(+), 32 deletions(-) > > diff --git a/include/linux/mm.h b/include/linux/mm.h > index dad667d99304..33cb3aa647a6 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -393,6 +393,19 @@ static inline int is_vmalloc_or_module_addr(const void *x) > > extern void kvfree(const void *addr); > > +static inline atomic_t *compound_mapcount_ptr(struct page *page) > +{ > + return &page[1].compound_mapcount; > +} > + > +static inline int compound_mapcount(struct page *page) > +{ > + if (!PageCompound(page)) > + return 0; > + page = compound_head(page); > + return atomic_read(compound_mapcount_ptr(page)) + 1; > +} > + > /* > * The atomic page->_mapcount, starts from -1: so that transitions > * both from it and to it can be tracked, using atomic_inc_and_test What's not shown here is the implementation of page_mapcount_reset() that's unchanged... is that correct from all callers? > @@ -405,8 +418,16 @@ static inline void page_mapcount_reset(struct page *page) > > static inline int page_mapcount(struct page *page) > { > + int ret; > VM_BUG_ON_PAGE(PageSlab(page), page); > - return atomic_read(&page->_mapcount) + 1; > + ret = atomic_read(&page->_mapcount) + 1; > + /* > + * Positive compound_mapcount() offsets ->_mapcount in every page by > + * one. Let's substract it here. > + */ This could use some more detailed explanation, or at least pointers to the relevant rmap functions. Also in commit message. > + if (compound_mapcount(page)) > + ret += compound_mapcount(page) - 1; This looks like it could uselessly duplicate-inline the code for compound_mapcount(). It has atomics and smp_rmb() so I'm not sure if the compiler can just "squash it". On the other hand, a simple atomic read that was page_mapcount() has turned into multiple atomic reads and flag checks. What about the stability of the whole result? Are all callers ok? (maybe a later page deals with it). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/