Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964894AbbENQH4 (ORCPT ); Thu, 14 May 2015 12:07:56 -0400 Received: from cantor2.suse.de ([195.135.220.15]:46410 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932459AbbENQHv (ORCPT ); Thu, 14 May 2015 12:07:51 -0400 Message-ID: <5554C854.6020900@suse.cz> Date: Thu, 14 May 2015 18:07:48 +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 02/28] rmap: add argument to charge compound page References: <1429823043-157133-1-git-send-email-kirill.shutemov@linux.intel.com> <1429823043-157133-3-git-send-email-kirill.shutemov@linux.intel.com> In-Reply-To: <1429823043-157133-3-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: 3041 Lines: 82 On 04/23/2015 11:03 PM, Kirill A. Shutemov wrote: > We're going to allow mapping of individual 4k pages of THP compound > page. It means we cannot rely on PageTransHuge() check to decide if > map/unmap small page or THP. > > The patch adds new argument to rmap functions to indicate whether we want > to operate on whole compound page or only the small page. > > Signed-off-by: Kirill A. Shutemov > Tested-by: Sasha Levin Acked-by: Vlastimil Babka But I wonder about one thing: > -void page_remove_rmap(struct page *page) > +void page_remove_rmap(struct page *page, bool compound) > { > + int nr = compound ? hpage_nr_pages(page) : 1; > + > if (!PageAnon(page)) { > + VM_BUG_ON_PAGE(compound && !PageHuge(page), page); > page_remove_file_rmap(page); > return; > } The function continues by: /* page still mapped by someone else? */ if (!atomic_add_negative(-1, &page->_mapcount)) return; /* Hugepages are not counted in NR_ANON_PAGES for now. */ if (unlikely(PageHuge(page))) return; The handling of compound parameter for PageHuge() pages feels just weird. You use hpage_nr_pages() for them which tests PageTransHuge(). It doesn't break anything and the value of nr is effectively ignored anyway, but still... So I wonder, if all callers of page_remove_rmap() for PageHuge() pages are the two in mm/hugetlb.c, why not just create a special case function? Or are some callers elsewhere, not aware whether they are calling this on a PageHuge()? So compound might be even false for those? If that's all possible and legal, then maybe explain it in a comment to reduce confusion of further readers. And move the 'nr' assignment to a place where we are sure it's not a PageHuge(), i.e. right above the place the value is used, perhaps? > @@ -1181,11 +1191,12 @@ void page_remove_rmap(struct page *page) > * these counters are not modified in interrupt context, and > * pte lock(a spinlock) is held, which implies preemption disabled. > */ > - if (PageTransHuge(page)) > + if (compound) { > + VM_BUG_ON_PAGE(!PageTransHuge(page), page); > __dec_zone_page_state(page, NR_ANON_TRANSPARENT_HUGEPAGES); > + } > > - __mod_zone_page_state(page_zone(page), NR_ANON_PAGES, > - -hpage_nr_pages(page)); > + __mod_zone_page_state(page_zone(page), NR_ANON_PAGES, -nr); > > if (unlikely(PageMlocked(page))) > clear_page_mlock(page); > @@ -1327,7 +1338,7 @@ static int try_to_unmap_one(struct page *page, struct vm_area_struct *vma, > dec_mm_counter(mm, MM_FILEPAGES); > > discard: > - page_remove_rmap(page); > + page_remove_rmap(page, false); > page_cache_release(page); > > out_unmap: -- 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/