[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1390856653-v1nkcg1e-mutt-n-horiguchi@ah.jp.nec.com>
Date: Mon, 27 Jan 2014 16:04:13 -0500
From: Naoya Horiguchi <n-horiguchi@...jp.nec.com>
To: Davidlohr Bueso <davidlohr@...com>
Cc: akpm@...ux-foundation.org, iamjoonsoo.kim@....com, riel@...hat.com,
mgorman@...e.de, mhocko@...e.cz, aneesh.kumar@...ux.vnet.ibm.com,
kamezawa.hiroyu@...fujitsu.com, hughd@...gle.com,
david@...son.dropbear.id.au, js1304@...il.com,
liwanp@...ux.vnet.ibm.com, dhillf@...il.com, rientjes@...gle.com,
aswin@...com, scott.norton@...com, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 6/8] mm, hugetlb: remove vma_has_reserves
On Sun, Jan 26, 2014 at 07:52:24PM -0800, Davidlohr Bueso wrote:
> From: Joonsoo Kim <iamjoonsoo.kim@....com>
>
> vma_has_reserves() can be substituted by using return value of
> vma_needs_reservation(). If chg returned by vma_needs_reservation()
> is 0, it means that vma has reserves. Otherwise, it means that vma don't
> have reserves and need a hugepage outside of reserve pool. This definition
> is perfectly same as vma_has_reserves(), so remove vma_has_reserves().
I'm concerned that this patch doesn't work when VM_NORESERVE is set.
vma_needs_reservation() doesn't check VM_NORESERVE and this patch changes
dequeue_huge_page_vma() not to check it. So no one seems to check it any more.
It would be nice if you add some comment about the justification in changelog.
Does the testcase attached in commit af0ed73e699b still pass with this patch?
(I'm not sure it's covered in libhugetlbfs test suite.)
Thanks,
Naoya Horiguchi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists