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=-2.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 DEC00C4320A for ; Mon, 23 Aug 2021 01:58:06 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7360561248 for ; Mon, 23 Aug 2021 01:58:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 7360561248 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id CA6F56B006C; Sun, 22 Aug 2021 21:58:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C56056B0072; Sun, 22 Aug 2021 21:58:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B45728D0001; Sun, 22 Aug 2021 21:58:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0142.hostedemail.com [216.40.44.142]) by kanga.kvack.org (Postfix) with ESMTP id 972206B006C for ; Sun, 22 Aug 2021 21:58:05 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 3EE39180C7165 for ; Mon, 23 Aug 2021 01:58:05 +0000 (UTC) X-FDA: 78504684930.08.080CF58 Received: from mail-yb1-f181.google.com (mail-yb1-f181.google.com [209.85.219.181]) by imf11.hostedemail.com (Postfix) with ESMTP id EE043F0000B0 for ; Mon, 23 Aug 2021 01:58:04 +0000 (UTC) Received: by mail-yb1-f181.google.com with SMTP id f15so2814834ybg.3 for ; Sun, 22 Aug 2021 18:58:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=wLsr+R0Fve9ivW+7qc/jUuotRZ00tnDPLOXaKuMzzD4=; b=RkT7Ab1TdRuLb9JbE9JxGn14hi9GH2rFmC4TG7zt/+6Ai+lnjwwfRqKVWumQIP1NHz TSwE5cSAXmTimpu03Q5vD3ve+pA3rlI0ZWUKLOq7Mh1//0bcuJ3PP6ZZEC5/jnZIjImj ZXKKvbwiPLSwLLv4pQneuFAMoiDrgjDFCzvM6XPhBAddFaszBV/NNQzXsCgVEWGlMQt4 53/NFAqgHiNJiVdCcDYIugaFG0paytp0T3hs6jBMsSzH64WkXPL88QKUK32ycBqo70xp dKtKHYYFqUXTwqOPO9emQvjbxRor4yx4e4pl/EScwhZE0tNjYn5bLTgmGhyG0Pf7FjWQ 0PFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wLsr+R0Fve9ivW+7qc/jUuotRZ00tnDPLOXaKuMzzD4=; b=G85KrTmcKoxfLhmUDPSd2RLFKj0g+8Lurh2DwBf7lTpxqMlslrHhh7F1rUqEU38RMA 4k5uhYDz//iDceIyWtcICj6E0s7jFHJK2et2Ys7URB8r0OwwdnSR0nh47BqCtm24OEJT frZAICDGTeZ5mGhrxHutQeDabpr6C3LTE2Nku0kUbSPd2dAsDIvzLbmUAzNdXcR7KkZh cJeBj0QsXrM6K+YDLDf8PpElP/fIwjaLW4BIbZSM2L1B2P3b8tPEwPgx0EutzYpLEzXY /tuRENS3aD1OVEFmjpfqRJRcW5jANfZnRF2OFhf6oZyxQz+vW0zlfF9onrEDOtuYqRTH /V7Q== X-Gm-Message-State: AOAM5309u/wtSgkkt5JwS9IiKbreXsdf69zaJrnjjgp2BP+t7/yUkMJP 4YDciOHeq3nh5zyV02nRs79NkPv5rG6ig3uW5/g= X-Google-Smtp-Source: ABdhPJxRvdQG0Ud1bze67w4fbPLedynZ27gerJNJTzB4xfNCcMWZBJ9gwk33CZztFXNBYImwJ9ALQOhaC6ZoSpzAyJk= X-Received: by 2002:a25:b7c8:: with SMTP id u8mr39872181ybj.268.1629683884334; Sun, 22 Aug 2021 18:58:04 -0700 (PDT) MIME-Version: 1.0 References: <20210820030536.25737-1-yaozhenguo1@gmail.com> <20210822151952.23ca9547316dc34c9f3bd482@linux-foundation.org> In-Reply-To: From: zhenguo yao Date: Mon, 23 Aug 2021 09:57:53 +0800 Message-ID: Subject: Re: [PATCH] hugetlbfs: add hugepages_node kernel parameter To: Matthew Wilcox Cc: mike.kravetz@oracle.com, corbet@lwn.net, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=RkT7Ab1T; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf11.hostedemail.com: domain of yaozhenguo1@gmail.com designates 209.85.219.181 as permitted sender) smtp.mailfrom=yaozhenguo1@gmail.com X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: EE043F0000B0 X-Stat-Signature: rnip9ianmzmb3z1agcromek3zup8i9ey X-HE-Tag: 1629683884-243747 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: Yes, the expanding of hugepages is more elegant. I will change it in the next version. Matthew Wilcox =E4=BA=8E2021=E5=B9=B48=E6=9C=8823=E6= =97=A5=E5=91=A8=E4=B8=80 =E4=B8=8A=E5=8D=886:28=E5=86=99=E9=81=93=EF=BC=9A > > On Sun, Aug 22, 2021 at 03:19:52PM -0700, Andrew Morton wrote: > > On Fri, 20 Aug 2021 11:05:36 +0800 yaozhenguo w= rote: > > > > > We can specify the number of hugepages to allocate at boot. But the > > > hugepages is balanced in all nodes at present. In some scenarios, > > > we only need hugepags in one node. For example: DPDK needs hugepages > > > which is in the same node as NIC. if DPDK needs four hugepags of 1G > > > size in node1 and system has 16 numa nodes. We must reserve 64 hugepa= gs > > > in kernel cmdline. But, only four hugepages is used. The others shoul= d > > > be free after boot.If the system memory is low(for example: 64G), it = will > > > be an impossible task. So, add hugepages_node kernel parameter to spe= cify > > > node number of hugepages to allocate at boot. > > > For example add following parameter: > > > > > > hugepagesz=3D1G hugepages_node=3D1 hugepages=3D4 > > > > > > It will allocate 4 hugepags in node1 at boot. > > > > If were going to do this, shouldn't we permit more than one node? > > > > hugepages_nodes=3D1,2,5 > > I'd think we'd be better off expanding the definition of hugepages. > eg: > > hugepagesz=3D1G hugepages=3D1:4,3:8,5:2 > > would say to allocate 4 pages from node 1, 8 pages from node 3 and 2 > pages from node 5.