lkml.org 
[lkml]   [2015]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: [PATCHv5 02/28] rmap: add argument to charge compound page
    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 <kirill.shutemov@linux.intel.com>
    > Tested-by: Sasha Levin <sasha.levin@oracle.com>

    Acked-by: Vlastimil Babka <vbabka@suse.cz>

    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:



    \
     
     \ /
      Last update: 2015-05-14 18:41    [W:4.616 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site