From: Michal Hocko <mhocko@kernel.org> To: Mike Kravetz <mike.kravetz@oracle.com> Cc: linux-mm@kvack.org, Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>, Andrew Morton <akpm@linux-foundation.org>, LKML <linux-kernel@vger.kernel.org> Subject: Re: [RFC PATCH 3/5] mm, hugetlb: do not rely on overcommit limit during migration Date: Thu, 14 Dec 2017 08:40:53 +0100 [thread overview] Message-ID: <20171214074053.GC16951@dhcp22.suse.cz> (raw) In-Reply-To: <ec386202-9bee-e230-1b37-bc05c4cd8f49@oracle.com> On Wed 13-12-17 15:35:33, Mike Kravetz wrote: > On 12/04/2017 06:01 AM, Michal Hocko wrote: [...] > > Before migration > > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/free_hugepages:0 > > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages:1 > > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/surplus_hugepages:0 > > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/free_hugepages:0 > > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages:0 > > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/surplus_hugepages:0 > > > > After > > > > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/free_hugepages:0 > > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages:0 > > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/surplus_hugepages:0 > > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/free_hugepages:0 > > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages:1 > > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/surplus_hugepages:0 > > > > with the previous implementation, both nodes would have nr_hugepages:1 > > until the page is freed. > > With the previous implementation, the migration would have failed unless > nr_overcommit_hugepages was explicitly set. Correct? yes [...] > In the previous version of this patch, I asked about handling of 'free' huge > pages. I did a little digging and IIUC, we do not attempt migration of > free huge pages. The routine isolate_huge_page() has this check: > > if (!page_huge_active(page) || !get_page_unless_zero(page)) { > ret = false; > goto unlock; > } > > I believe one of your motivations for this effort was memory offlining. > So, this implies that a memory area can not be offlined if it contains > a free (not in use) huge page? do_migrate_range will ignore this free huge page and then we will free it up in dissolve_free_huge_pages > Just FYI and may be something we want to address later. Maybe yes. The free pool might be reserved which would make dissolve_free_huge_pages to fail. Maybe we can be more clever and allocate a new huge page in that case. > My other issues were addressed. > > Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com> Thanks! -- Michal Hocko SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org> To: Mike Kravetz <mike.kravetz@oracle.com> Cc: linux-mm@kvack.org, Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>, Andrew Morton <akpm@linux-foundation.org>, LKML <linux-kernel@vger.kernel.org> Subject: Re: [RFC PATCH 3/5] mm, hugetlb: do not rely on overcommit limit during migration Date: Thu, 14 Dec 2017 08:40:53 +0100 [thread overview] Message-ID: <20171214074053.GC16951@dhcp22.suse.cz> (raw) In-Reply-To: <ec386202-9bee-e230-1b37-bc05c4cd8f49@oracle.com> On Wed 13-12-17 15:35:33, Mike Kravetz wrote: > On 12/04/2017 06:01 AM, Michal Hocko wrote: [...] > > Before migration > > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/free_hugepages:0 > > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages:1 > > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/surplus_hugepages:0 > > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/free_hugepages:0 > > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages:0 > > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/surplus_hugepages:0 > > > > After > > > > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/free_hugepages:0 > > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages:0 > > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/surplus_hugepages:0 > > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/free_hugepages:0 > > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages:1 > > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/surplus_hugepages:0 > > > > with the previous implementation, both nodes would have nr_hugepages:1 > > until the page is freed. > > With the previous implementation, the migration would have failed unless > nr_overcommit_hugepages was explicitly set. Correct? yes [...] > In the previous version of this patch, I asked about handling of 'free' huge > pages. I did a little digging and IIUC, we do not attempt migration of > free huge pages. The routine isolate_huge_page() has this check: > > if (!page_huge_active(page) || !get_page_unless_zero(page)) { > ret = false; > goto unlock; > } > > I believe one of your motivations for this effort was memory offlining. > So, this implies that a memory area can not be offlined if it contains > a free (not in use) huge page? do_migrate_range will ignore this free huge page and then we will free it up in dissolve_free_huge_pages > Just FYI and may be something we want to address later. Maybe yes. The free pool might be reserved which would make dissolve_free_huge_pages to fail. Maybe we can be more clever and allocate a new huge page in that case. > My other issues were addressed. > > Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com> Thanks! -- 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:[~2017-12-14 7:40 UTC|newest] Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-12-04 14:01 [RFC PATCH 0/5] mm, hugetlb: allocation API and migration improvements Michal Hocko 2017-12-04 14:01 ` Michal Hocko 2017-12-04 14:01 ` [RFC PATCH 1/5] mm, hugetlb: unify core page allocation accounting and initialization Michal Hocko 2017-12-04 14:01 ` Michal Hocko 2017-12-13 0:20 ` Mike Kravetz 2017-12-13 0:20 ` Mike Kravetz 2017-12-04 14:01 ` [RFC PATCH 2/5] mm, hugetlb: integrate giga hugetlb more naturally to the allocation path Michal Hocko 2017-12-04 14:01 ` Michal Hocko 2017-12-13 0:24 ` Mike Kravetz 2017-12-13 0:24 ` Mike Kravetz 2017-12-04 14:01 ` [RFC PATCH 3/5] mm, hugetlb: do not rely on overcommit limit during migration Michal Hocko 2017-12-04 14:01 ` Michal Hocko 2017-12-13 23:35 ` Mike Kravetz 2017-12-13 23:35 ` Mike Kravetz 2017-12-14 7:40 ` Michal Hocko [this message] 2017-12-14 7:40 ` Michal Hocko 2017-12-14 20:57 ` Mike Kravetz 2017-12-14 20:57 ` Mike Kravetz 2017-12-04 14:01 ` [RFC PATCH 4/5] mm, hugetlb: get rid of surplus page accounting tricks Michal Hocko 2017-12-04 14:01 ` Michal Hocko 2017-12-14 0:45 ` Mike Kravetz 2017-12-14 0:45 ` Mike Kravetz 2017-12-14 7:50 ` Michal Hocko 2017-12-14 7:50 ` Michal Hocko 2017-12-14 20:58 ` Mike Kravetz 2017-12-14 20:58 ` Mike Kravetz 2017-12-04 14:01 ` [RFC PATCH 5/5] mm, hugetlb: further simplify hugetlb allocation API Michal Hocko 2017-12-04 14:01 ` Michal Hocko 2017-12-14 21:01 ` Mike Kravetz 2017-12-14 21:01 ` Mike Kravetz 2017-12-15 9:33 ` [RFC PATCH 0/5] mm, hugetlb: allocation API and migration improvements Michal Hocko 2017-12-15 9:33 ` Michal Hocko 2017-12-20 5:33 ` Naoya Horiguchi 2017-12-20 5:33 ` Naoya Horiguchi 2017-12-20 9:53 ` Michal Hocko 2017-12-20 9:53 ` Michal Hocko 2017-12-20 22:43 ` Mike Kravetz 2017-12-20 22:43 ` Mike Kravetz 2017-12-21 7:28 ` Michal Hocko 2017-12-21 7:28 ` Michal Hocko 2017-12-21 23:35 ` Mike Kravetz 2017-12-21 23:35 ` Mike Kravetz 2017-12-22 9:48 ` Michal Hocko 2017-12-22 9:48 ` Michal Hocko 2017-12-22 8:58 ` Naoya Horiguchi 2017-12-22 8:58 ` Naoya Horiguchi
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=20171214074053.GC16951@dhcp22.suse.cz \ --to=mhocko@kernel.org \ --cc=akpm@linux-foundation.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.