Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1459212
| From | Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH] mm: fix the incorrect hugepages count |
| Date | 2016-08-10 02:20 +0200 |
| Message-ID | <s4ppv-6cf-11@gated-at.bofh.it> (permalink) |
| References | <s3IXg-3Tl-3@gated-at.bofh.it> <s3Wnv-4d0-7@gated-at.bofh.it> <s4cBY-6kP-23@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Tue, Aug 09, 2016 at 06:32:39PM +0800, zhong jiang wrote: > On 2016/8/9 1:14, Mike Kravetz wrote: > > On 08/07/2016 07:49 PM, zhongjiang wrote: > >> From: zhong jiang <zhongjiang@huawei.com> > >> > >> when memory hotplug enable, free hugepages will be freed if movable node offline. > >> therefore, /proc/sys/vm/nr_hugepages will be incorrect. This sounds a bit odd to me because /proc/sys/vm/nr_hugepages returns h->nr_huge_pages or h->nr_huge_pages_node[nid], which is already considered in dissolve_free_huge_page (via update_and_free_page). I think that h->max_huge_pages effectively means the pool size, and h->nr_huge_pages means total hugepage number (which can be greater than the pool size when there's overcommiting/surplus.) dissolve_free_huge_page intends to break a hugepage into buddy, and the destination hugepage is supposed to be allocated from the pool of the destination node, so the system-wide pool size is reduced. So adding h->max_huge_pages-- makes sense to me. Acked-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> > >> > >> The patch fix it by reduce the max_huge_pages when the node offline. > >> > >> Signed-off-by: zhong jiang <zhongjiang@huawei.com> > >> --- > >> mm/hugetlb.c | 1 + > >> 1 file changed, 1 insertion(+) > >> > >> diff --git a/mm/hugetlb.c b/mm/hugetlb.c > >> index f904246..3356e3a 100644 > >> --- a/mm/hugetlb.c > >> +++ b/mm/hugetlb.c > >> @@ -1448,6 +1448,7 @@ static void dissolve_free_huge_page(struct page *page) > >> list_del(&page->lru); > >> h->free_huge_pages--; > >> h->free_huge_pages_node[nid]--; > >> + h->max_huge_pages--; > >> update_and_free_page(h, page); > >> } > >> spin_unlock(&hugetlb_lock); > >> > > Adding Naoya as he was the original author of this code. > > > > >From quick look it appears that the huge page will be migrated (allocated > > on another node). If my understanding is correct, then max_huge_pages > > should not be adjusted here. > > > we need to take free hugetlb pages into account. of course, the allocated huge pages is no > need to reduce. The patch just reduce the free hugetlb pages count. I
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
[PATCH] mm: fix the incorrect hugepages count zhongjiang <zhongjiang@huawei.com> - 2016-08-08 05:00 +0200
Re: [PATCH] mm: fix the incorrect hugepages count Mike Kravetz <mike.kravetz@oracle.com> - 2016-08-08 19:20 +0200
Re: [PATCH] mm: fix the incorrect hugepages count zhong jiang <zhongjiang@huawei.com> - 2016-08-09 12:40 +0200
Re: [PATCH] mm: fix the incorrect hugepages count Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> - 2016-08-10 02:20 +0200
csiph-web