From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2FB90C433E2 for ; Wed, 2 Sep 2020 06:14:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EBEEE20665 for ; Wed, 2 Sep 2020 06:14:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EBEEE20665 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5593A6B0037; Wed, 2 Sep 2020 02:14:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5096E6B0055; Wed, 2 Sep 2020 02:14:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 41FC26B005A; Wed, 2 Sep 2020 02:14:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0134.hostedemail.com [216.40.44.134]) by kanga.kvack.org (Postfix) with ESMTP id 2954E6B0037 for ; Wed, 2 Sep 2020 02:14:28 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id DDBDF362B for ; Wed, 2 Sep 2020 06:14:27 +0000 (UTC) X-FDA: 77217106974.30.sound70_53172b12709e Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin30.hostedemail.com (Postfix) with ESMTP id ADC05180B3AA7 for ; Wed, 2 Sep 2020 06:14:27 +0000 (UTC) X-HE-Tag: sound70_53172b12709e X-Filterd-Recvd-Size: 4178 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf41.hostedemail.com (Postfix) with ESMTP for ; Wed, 2 Sep 2020 06:14:27 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 0826EACC5; Wed, 2 Sep 2020 06:14:27 +0000 (UTC) Date: Wed, 2 Sep 2020 08:14:25 +0200 From: Michal Hocko To: Li Xinhai Cc: linux-mm@kvack.org, akpm@linux-foundation.org, Roman Gushchin , Mike Kravetz Subject: Re: [PATCH V3] mm/hugetlb: try preferred node first when alloc gigantic page from cma Message-ID: <20200902061425.GB6363@dhcp22.suse.cz> References: <20200902025016.697260-1-lixinhai.lxh@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200902025016.697260-1-lixinhai.lxh@gmail.com> X-Rspamd-Queue-Id: ADC05180B3AA7 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed 02-09-20 10:50:16, Li Xinhai wrote: > Since commit cf11e85fc08cc6a4 ("mm: hugetlb: optionally allocate gigantic > hugepages using cma"), the gigantic page would be allocated from node > which is not the preferred node, although there are pages available from > that node. The reason is that the nid parameter has been ignored in > alloc_gigantic_page(). > > Besides, the __GFP_THISNODE also need be checked if user required to > alloc only from the preferred node. > > After this patch, the preferred node is tried first before other allowed > nodes, and don't try to allocate from other nodes if __GFP_THISNODE is > specified. If user don't specify the preferred node, the current node > will be used as preferred node, which makes sure consistent behavior of > allocating gigantic and non-gigantic hugetlb page. Technically speaking this is still not in full sync with the allocator semantic. E.g. cma allocator should try nodes in the node distance order. Possible but not sure how much we really do care for those who preallocate cma pools. Also __GFP_NOWAIT should skip CMA as that requires mutex - or even better make alloc_cma gfp aware. Likely few more things. If we care then something for a patch or two on its own and also make the cma part a function on its own to remove the ugly ifdef. > Fixes: cf11e85fc08cc6a4 ("mm: hugetlb: optionally allocate gigantic hugepages using cma") > Cc: Roman Gushchin > Cc: Mike Kravetz > Cc: Michal Hocko > Signed-off-by: Li Xinhai Acked-by: Michal Hocko Thanks! > --- > v2->V3 > Consider current node as preferred node if nid is NUMA_NO_NODE, thanks > Mike. > > v1->v2: > With review by Mike and Michal, need to check __GFP_THISNODE to avoid > allocate from other nodes. > > mm/hugetlb.c | 23 +++++++++++++++++------ > 1 file changed, 17 insertions(+), 6 deletions(-) > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > index a301c2d672bf..5957dc80ebb1 100644 > --- a/mm/hugetlb.c > +++ b/mm/hugetlb.c > @@ -1250,21 +1250,32 @@ static struct page *alloc_gigantic_page(struct hstate *h, gfp_t gfp_mask, > int nid, nodemask_t *nodemask) > { > unsigned long nr_pages = 1UL << huge_page_order(h); > + if (nid == NUMA_NO_NODE) > + nid = numa_mem_id(); > > #ifdef CONFIG_CMA > { > struct page *page; > int node; > > - for_each_node_mask(node, *nodemask) { > - if (!hugetlb_cma[node]) > - continue; > - > - page = cma_alloc(hugetlb_cma[node], nr_pages, > - huge_page_order(h), true); > + if (hugetlb_cma[nid]) { > + page = cma_alloc(hugetlb_cma[nid], nr_pages, > + huge_page_order(h), true); > if (page) > return page; > } > + > + if (!(gfp_mask & __GFP_THISNODE)) { > + for_each_node_mask(node, *nodemask) { > + if (node == nid || !hugetlb_cma[node]) > + continue; > + > + page = cma_alloc(hugetlb_cma[node], nr_pages, > + huge_page_order(h), true); > + if (page) > + return page; > + } > + } > } > #endif > > -- > 2.18.4 -- Michal Hocko SUSE Labs