Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1398467yba; Tue, 2 Apr 2019 08:09:59 -0700 (PDT) X-Google-Smtp-Source: APXvYqzDuNpuemlkK6DBA4MZQ0CCWIFPJSXpo4hL9BFhigVMy435FhuyXulRbj0Nec3hQv/p5Uzz X-Received: by 2002:a63:6941:: with SMTP id e62mr7269524pgc.99.1554217799212; Tue, 02 Apr 2019 08:09:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554217799; cv=none; d=google.com; s=arc-20160816; b=PTSc7j/akPf69lHvbov7p01WcDZIBjh4MTXJ1t41bHFYb26Ewo9gdsKwrpyFqCHAmn BIWn2OIwyEGbcCHZnklLqf2TIqesGl1lBKVU/c4eZhJyEbiMuTFfWTA4AX424lfSm4MO LqsrAuZfLKqLiorQwHg3e4AyAZcZNNp81hQqhznYue83eJkjUhRA6E1NH3HykpVevnVK VT+uud71jpUGb4U6G3fVq5UYmCr+AjTQkdwSqzCrLNA50HrWB3V+fme5n914JaPR0WIp P11vF9R+5ZnQtnV9vO5RgdvekYN4yJZvrWLSNk4Gv3sP5amqn7vZuHE7i0OYzR//ONtx Nx3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from; bh=RMLFIHHn6ZSoN0mvOloEDz0gW7wVGrtydCF6IfgZcKw=; b=Zd1VjVwD4vCGXFuVXSJaLy3Te4NRc5J9e+UVCisLBWXJvlQk8lfc6+yuui/S1682bB Fd5449+XwctJNgJDkI8tW0Q4PyOmbug8cJeXvqRAuXymptOaseiMfvr9cNdYIb8avP3p xFmpu2kQaCV4FmwP2k/ZCrfqmWRjXJwPJWPz3tdCY5YNmuab8yPjvJIF5g6/3D687lht 9H/aF0GuhhC07fWtA4FqOOw4IHo3h4GLtLDv3I2RsIeHZYvUW3W9OjTvnC0/m+kuEl4a TUWueGj6B0rAl8VVq1BMHBxL0ZUVtf04I8FPLAjnmDT7aV6Nrj8sW5QHOvGOILaeGK7Z JG0w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 5si11551571pgg.505.2019.04.02.08.09.43; Tue, 02 Apr 2019 08:09:59 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730219AbfDBNeg (ORCPT + 99 others); Tue, 2 Apr 2019 09:34:36 -0400 Received: from smtp.nue.novell.com ([195.135.221.5]:40310 "EHLO smtp.nue.novell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725920AbfDBNef (ORCPT ); Tue, 2 Apr 2019 09:34:35 -0400 Received: from emea4-mta.ukb.novell.com ([10.120.13.87]) by smtp.nue.novell.com with ESMTP (TLS encrypted); Tue, 02 Apr 2019 15:34:34 +0200 Received: from d104.suse.de (nwb-a10-snat.microfocus.com [10.120.13.202]) by emea4-mta.ukb.novell.com with ESMTP (NOT encrypted); Tue, 02 Apr 2019 14:34:21 +0100 From: Oscar Salvador To: akpm@linux-foundation.org Cc: mike.kravetz@oracle.com, n-horiguchi@ah.jp.nec.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Oscar Salvador Subject: [PATCH] mm/hugetlb: Get rid of NODEMASK_ALLOC Date: Tue, 2 Apr 2019 15:34:15 +0200 Message-Id: <20190402133415.21983-1-osalvador@suse.de> X-Mailer: git-send-email 2.13.7 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org NODEMASK_ALLOC is used to allocate a nodemask bitmap, ant it does it by first determining whether it should be allocated in the stack or dinamically depending on NODES_SHIFT. Right now, it goes the dynamic path whenever the nodemask_t is above 32 bytes. Although we could bump it to a reasonable value, the largest a nodemask_t can get is 128 bytes, so since __nr_hugepages_store_common is called from a rather shore stack we can just get rid of the NODEMASK_ALLOC call here. This reduces some code churn and complexity. Signed-off-by: Oscar Salvador --- mm/hugetlb.c | 36 +++++++++++------------------------- 1 file changed, 11 insertions(+), 25 deletions(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index f79ae4e42159..9cb2f91af897 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -2447,44 +2447,30 @@ static ssize_t __nr_hugepages_store_common(bool obey_mempolicy, unsigned long count, size_t len) { int err; - NODEMASK_ALLOC(nodemask_t, nodes_allowed, GFP_KERNEL | __GFP_NORETRY); + nodemask_t nodes_allowed, *n_mask; - if (hstate_is_gigantic(h) && !gigantic_page_runtime_supported()) { - err = -EINVAL; - goto out; - } + if (hstate_is_gigantic(h) && !gigantic_page_runtime_supported()) + return -EINVAL; if (nid == NUMA_NO_NODE) { /* * global hstate attribute */ if (!(obey_mempolicy && - init_nodemask_of_mempolicy(nodes_allowed))) { - NODEMASK_FREE(nodes_allowed); - nodes_allowed = &node_states[N_MEMORY]; - } - } else if (nodes_allowed) { + init_nodemask_of_mempolicy(&nodes_allowed))) + n_mask = &node_states[N_MEMORY]; + else + n_mask = &nodes_allowed; + } else { /* * Node specific request. count adjustment happens in * set_max_huge_pages() after acquiring hugetlb_lock. */ - init_nodemask_of_node(nodes_allowed, nid); - } else { - /* - * Node specific request, but we could not allocate the few - * words required for a node mask. We are unlikely to hit - * this condition. Since we can not pass down the appropriate - * node mask, just return ENOMEM. - */ - err = -ENOMEM; - goto out; + init_nodemask_of_node(&nodes_allowed, nid); + n_mask = &nodes_allowed; } - err = set_max_huge_pages(h, count, nid, nodes_allowed); - -out: - if (nodes_allowed != &node_states[N_MEMORY]) - NODEMASK_FREE(nodes_allowed); + err = set_max_huge_pages(h, count, nid, n_mask); return err ? err : len; } -- 2.13.7