From: Michal Hocko <mhocko@kernel.org> To: Dan Rue <dan.rue@linaro.org> Cc: Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org, Mike Kravetz <mike.kravetz@oracle.com>, Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>, LKML <linux-kernel@vger.kernel.org> Subject: Re: [PATCH 5/6] mm, hugetlb: further simplify hugetlb allocation API Date: Wed, 21 Feb 2018 10:55:26 +0100 [thread overview] Message-ID: <20180221095526.GB2231@dhcp22.suse.cz> (raw) In-Reply-To: <20180221042457.uolmhlmv5je5dqx7@xps> On Tue 20-02-18 22:24:57, Dan Rue wrote: > On Wed, Jan 03, 2018 at 10:32:12AM +0100, Michal Hocko wrote: > > From: Michal Hocko <mhocko@suse.com> > > > > Hugetlb allocator has several layer of allocation functions depending > > and the purpose of the allocation. There are two allocators depending > > on whether the page can be allocated from the page allocator or we need > > a contiguous allocator. This is currently opencoded in alloc_fresh_huge_page > > which is the only path that might allocate giga pages which require the > > later allocator. Create alloc_fresh_huge_page which hides this > > implementation detail and use it in all callers which hardcoded the > > buddy allocator path (__hugetlb_alloc_buddy_huge_page). This shouldn't > > introduce any funtional change because both migration and surplus > > allocators exlude giga pages explicitly. > > > > While we are at it let's do some renaming. The current scheme is not > > consistent and overly painfull to read and understand. Get rid of prefix > > underscores from most functions. There is no real reason to make names > > longer. > > * alloc_fresh_huge_page is the new layer to abstract underlying > > allocator > > * __hugetlb_alloc_buddy_huge_page becomes shorter and neater > > alloc_buddy_huge_page. > > * Former alloc_fresh_huge_page becomes alloc_pool_huge_page because we put > > the new page directly to the pool > > * alloc_surplus_huge_page can drop the opencoded prep_new_huge_page code > > as it uses alloc_fresh_huge_page now > > * others lose their excessive prefix underscores to make names shorter > > Hi Michal - > > We (Linaro) run the libhugetlbfs test suite continuously against > mainline and recently (Feb 1), the 'counters' test started failing on > with the following error: > > root@localhost:~# mount_point="/mnt/hugetlb/" > root@localhost:~# echo 200 > /proc/sys/vm/nr_hugepages > root@localhost:~# mkdir -p "${mount_point}" > root@localhost:~# mount -t hugetlbfs hugetlbfs "${mount_point}" > root@localhost:~# export LD_LIBRARY_PATH=/root/libhugetlbfs/libhugetlbfs-2.20/obj64 > root@localhost:~# /root/libhugetlbfs/libhugetlbfs-2.20/tests/obj64/counters > Starting testcase "/root/libhugetlbfs/libhugetlbfs-2.20/tests/obj64/counters", pid 3319 > Base pool size: 0 > Clean... > FAIL Line 326: Bad HugePages_Total: expected 0, actual 1 > > Line 326 refers to the test source @ > https://github.com/libhugetlbfs/libhugetlbfs/blob/master/tests/counters.c#L326 Thanks for the report. I am fighting to get hugetlb tests working. My previous deployment is gone and the new git snapshot fails to build. I will look into it further but ... > I bisected the failure to this commit. The problem is seen on multiple > architectures (tested x86-64 and arm64). The patch shouldn't have introduced any functional changes IIRC. But let me have a look -- Michal Hocko SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org> To: Dan Rue <dan.rue@linaro.org> Cc: Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org, Mike Kravetz <mike.kravetz@oracle.com>, Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>, LKML <linux-kernel@vger.kernel.org> Subject: Re: [PATCH 5/6] mm, hugetlb: further simplify hugetlb allocation API Date: Wed, 21 Feb 2018 10:55:26 +0100 [thread overview] Message-ID: <20180221095526.GB2231@dhcp22.suse.cz> (raw) In-Reply-To: <20180221042457.uolmhlmv5je5dqx7@xps> On Tue 20-02-18 22:24:57, Dan Rue wrote: > On Wed, Jan 03, 2018 at 10:32:12AM +0100, Michal Hocko wrote: > > From: Michal Hocko <mhocko@suse.com> > > > > Hugetlb allocator has several layer of allocation functions depending > > and the purpose of the allocation. There are two allocators depending > > on whether the page can be allocated from the page allocator or we need > > a contiguous allocator. This is currently opencoded in alloc_fresh_huge_page > > which is the only path that might allocate giga pages which require the > > later allocator. Create alloc_fresh_huge_page which hides this > > implementation detail and use it in all callers which hardcoded the > > buddy allocator path (__hugetlb_alloc_buddy_huge_page). This shouldn't > > introduce any funtional change because both migration and surplus > > allocators exlude giga pages explicitly. > > > > While we are at it let's do some renaming. The current scheme is not > > consistent and overly painfull to read and understand. Get rid of prefix > > underscores from most functions. There is no real reason to make names > > longer. > > * alloc_fresh_huge_page is the new layer to abstract underlying > > allocator > > * __hugetlb_alloc_buddy_huge_page becomes shorter and neater > > alloc_buddy_huge_page. > > * Former alloc_fresh_huge_page becomes alloc_pool_huge_page because we put > > the new page directly to the pool > > * alloc_surplus_huge_page can drop the opencoded prep_new_huge_page code > > as it uses alloc_fresh_huge_page now > > * others lose their excessive prefix underscores to make names shorter > > Hi Michal - > > We (Linaro) run the libhugetlbfs test suite continuously against > mainline and recently (Feb 1), the 'counters' test started failing on > with the following error: > > root@localhost:~# mount_point="/mnt/hugetlb/" > root@localhost:~# echo 200 > /proc/sys/vm/nr_hugepages > root@localhost:~# mkdir -p "${mount_point}" > root@localhost:~# mount -t hugetlbfs hugetlbfs "${mount_point}" > root@localhost:~# export LD_LIBRARY_PATH=/root/libhugetlbfs/libhugetlbfs-2.20/obj64 > root@localhost:~# /root/libhugetlbfs/libhugetlbfs-2.20/tests/obj64/counters > Starting testcase "/root/libhugetlbfs/libhugetlbfs-2.20/tests/obj64/counters", pid 3319 > Base pool size: 0 > Clean... > FAIL Line 326: Bad HugePages_Total: expected 0, actual 1 > > Line 326 refers to the test source @ > https://github.com/libhugetlbfs/libhugetlbfs/blob/master/tests/counters.c#L326 Thanks for the report. I am fighting to get hugetlb tests working. My previous deployment is gone and the new git snapshot fails to build. I will look into it further but ... > I bisected the failure to this commit. The problem is seen on multiple > architectures (tested x86-64 and arm64). The patch shouldn't have introduced any functional changes IIRC. But let me have a look -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2018-02-21 9:55 UTC|newest] Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-01-03 9:32 [PATCH 0/6] mm, hugetlb: allocation API and migration improvements Michal Hocko 2018-01-03 9:32 ` Michal Hocko 2018-01-03 9:32 ` [PATCH 1/6] mm, hugetlb: unify core page allocation accounting and initialization Michal Hocko 2018-01-03 9:32 ` Michal Hocko 2018-01-03 9:32 ` [PATCH 2/6] mm, hugetlb: integrate giga hugetlb more naturally to the allocation path Michal Hocko 2018-01-03 9:32 ` Michal Hocko 2018-01-03 9:32 ` [PATCH 3/6] mm, hugetlb: do not rely on overcommit limit during migration Michal Hocko 2018-01-03 9:32 ` Michal Hocko 2018-01-03 9:32 ` [PATCH 4/6] mm, hugetlb: get rid of surplus page accounting tricks Michal Hocko 2018-01-03 9:32 ` Michal Hocko 2018-01-03 9:32 ` [PATCH 5/6] mm, hugetlb: further simplify hugetlb allocation API Michal Hocko 2018-01-03 9:32 ` Michal Hocko 2018-02-21 4:24 ` Dan Rue 2018-02-21 4:24 ` Dan Rue 2018-02-21 9:55 ` Michal Hocko [this message] 2018-02-21 9:55 ` Michal Hocko 2018-02-21 10:01 ` Michal Hocko 2018-02-21 10:01 ` Michal Hocko 2018-02-21 16:19 ` Dan Rue 2018-02-21 16:19 ` Dan Rue 2018-02-21 18:52 ` Michal Hocko 2018-02-21 18:52 ` Michal Hocko 2018-02-21 19:05 ` Dan Rue 2018-02-21 19:05 ` Dan Rue 2018-02-21 17:59 ` Mike Kravetz 2018-02-21 17:59 ` Mike Kravetz 2018-02-21 18:54 ` Michal Hocko 2018-02-21 18:54 ` Michal Hocko 2018-02-21 19:14 ` [PATCH] hugetlb: fix surplus pages accounting Michal Hocko 2018-02-21 19:14 ` Michal Hocko 2018-01-03 9:32 ` [PATCH 6/6] hugetlb, mempolicy: fix the mbind hugetlb migration Michal Hocko 2018-01-03 9:32 ` Michal Hocko 2018-01-04 0:05 ` [PATCH 0/6] mm, hugetlb: allocation API and migration improvements Andrew Morton 2018-01-04 0:05 ` Andrew Morton 2018-01-04 7:32 ` Michal Hocko 2018-01-04 7:32 ` Michal Hocko
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20180221095526.GB2231@dhcp22.suse.cz \ --to=mhocko@kernel.org \ --cc=akpm@linux-foundation.org \ --cc=dan.rue@linaro.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mike.kravetz@oracle.com \ --cc=n-horiguchi@ah.jp.nec.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.