From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751355AbdK0GoN (ORCPT ); Mon, 27 Nov 2017 01:44:13 -0500 Received: from tyo161.gate.nec.co.jp ([114.179.232.161]:42817 "EHLO tyo161.gate.nec.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751156AbdK0GoL (ORCPT ); Mon, 27 Nov 2017 01:44:11 -0500 From: Naoya Horiguchi To: Mike Kravetz , Michal Hocko , "linux-mm@kvack.org" CC: Naoya Horiguchi , LKML Subject: Re: hugetlb page migration vs. overcommit Thread-Topic: hugetlb page migration vs. overcommit Thread-Index: AQHTY6aRDhNpOYT2nE6Rc/8od9ckuaMgLUQAgAcGMAA= Date: Mon, 27 Nov 2017 06:27:36 +0000 Message-ID: <4c97aaf2-19ed-b45c-e61a-fa9510cd9ddf@ah.jp.nec.com> References: <20171122152832.iayefrlxbugphorp@dhcp22.suse.cz> <91969714-5256-e96f-a48b-43af756a2686@oracle.com> In-Reply-To: <91969714-5256-e96f-a48b-43af756a2686@oracle.com> Accept-Language: en-US, ja-JP Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.128.101.27] Content-Type: text/plain; charset="utf-8" Content-ID: <0430D7B812B862409056DAEAE92916D4@gisp.nec.co.jp> MIME-Version: 1.0 X-TM-AS-MML: disable Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id vAR6iHda024131 On 11/23/2017 04:11 AM, Mike Kravetz wrote: > On 11/22/2017 07:28 AM, Michal Hocko wrote: >> Hi, >> is there any reason why we enforce the overcommit limit during hugetlb >> pages migration? It's in alloc_huge_page_node->__alloc_buddy_huge_page >> path. I am wondering whether this is really an intentional behavior. > > I do not think it was intentional. But, I was not around when that > code was added. > >> The page migration allocates a page just temporarily so we should be >> able to go over the overcommit limit for the migration duration. The >> reason I am asking is that hugetlb pages tend to be utilized usually >> (otherwise the memory would be just wasted and pool shrunk) but then >> the migration simply fails which breaks memory hotplug and other >> migration dependent functionality which is quite suboptimal. You can >> workaround that by increasing the overcommit limit. > > Yes. In an environment making optimal use of huge pages, you are unlikely > to have 'spare pages' set aside for a potential migration operation. So > I agree that it would make sense to try and allocate overcommit pages for > this purpose. Thank you for pointing this out, Michal, Mike. Doing overcommitting in hugepage migration is totally right to me, I just didn't notice it when I wrote the code. > >> Why don't we simply migrate as long as we are able to allocate the >> target hugetlb page? I have a half baked patch to remove this >> restriction, would there be an opposition to do something like that? > > I would not be opposed and would help with this effort. My concern would > be any subtle hugetlb accounting issues once you start messing with > additional overcommit pages. Yes, hugetlb accounting always needs care when touching related code. I can help testing. Thanks, Naoya Horiguchi