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=-8.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable 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 4FFB6C10DCE for ; Tue, 24 Mar 2020 03:47:56 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 210632073E for ; Tue, 24 Mar 2020 03:47:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="mSOqJupw" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 210632073E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=8sgxs+owglEwvLH6uh2rDHWYITekzZHwgbeElUs0iyU=; b=mSOqJupwOZs2pC 8nYeWEVIJ+4FWQGhwlFCVqyL9O43xdim7NnEZvi6xmBKpsJa/A1jgHQhX9Uzv3TSlHu94Eri/Z1Su ACxbbPZAjTcgU6XtdJ/CHzA8CKwSTTzSeFV0NW4qq+dv6lXuQSDEDaK12vicDy772eeT7ob4mM8iJ WI0eP5p3h23BFqjkZIZNuLCegmeAoa4y8xg3cOcO9qHmzl3Te8t1FgSdFxb1t6hTtAUpt00S+a6e8 kyTJWSyMtTOrK1v7r7DPagRRIELycXU4nR8TS59ZDWQOIBJ7FAS9o7KblGvq0bhtRrLjJME/HyJGh EHO7ULnBNtD+e4PbzjvQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jGaXi-0003La-2f; Tue, 24 Mar 2020 03:47:54 +0000 Received: from szxga05-in.huawei.com ([45.249.212.191] helo=huawei.com) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jGaXd-0003KC-DM; Tue, 24 Mar 2020 03:47:52 +0000 Received: from DGGEMS402-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 7CA9B539151FD28DDA6A; Tue, 24 Mar 2020 11:47:38 +0800 (CST) Received: from [10.173.228.124] (10.173.228.124) by smtp.huawei.com (10.3.19.202) with Microsoft SMTP Server (TLS) id 14.3.487.0; Tue, 24 Mar 2020 11:47:36 +0800 Subject: Re: [PATCH 4/4] hugetlbfs: clean up command line processing To: Mina Almasry , Mike Kravetz References: <20200318220634.32100-1-mike.kravetz@oracle.com> <20200318220634.32100-5-mike.kravetz@oracle.com> From: "Longpeng (Mike, Cloud Infrastructure Service Product Dept.)" Message-ID: Date: Tue, 24 Mar 2020 11:47:35 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Originating-IP: [10.173.228.124] X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200323_204749_796668_22326B25 X-CRM114-Status: GOOD ( 30.14 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-doc@vger.kernel.org, Catalin Marinas , Dave Hansen , Heiko Carstens , Linux-MM , Paul Mackerras , sparclinux@vger.kernel.org, linux-riscv@lists.infradead.org, Will Deacon , linux-s390@vger.kernel.org, Jonathan Corbet , Christian Borntraeger , Ingo Molnar , Benjamin Herrenschmidt , Albert Ou , Vasily Gorbik , Paul Walmsley , Thomas Gleixner , linux-arm-kernel@lists.infradead.org, open list , Palmer Dabbelt , Andrew Morton , linuxppc-dev@lists.ozlabs.org, "David S . Miller" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2020/3/24 8:43, Mina Almasry wrote: > On Wed, Mar 18, 2020 at 3:07 PM Mike Kravetz wrote: >> >> With all hugetlb page processing done in a single file clean up code. > > Now that all hugepage page processing is done in a single file, clean > up the code. > >> - Make code match desired semantics >> - Update documentation with semantics >> - Make all warnings and errors messages start with 'HugeTLB:'. >> - Consistently name command line parsing routines. >> - Add comments to code >> - Describe some of the subtle interactions >> - Describe semantics of command line arguments >> >> Signed-off-by: Mike Kravetz >> --- >> Documentation/admin-guide/mm/hugetlbpage.rst | 26 +++++++ >> mm/hugetlb.c | 78 +++++++++++++++----- >> 2 files changed, 87 insertions(+), 17 deletions(-) >> >> diff --git a/Documentation/admin-guide/mm/hugetlbpage.rst b/Documentation/admin-guide/mm/hugetlbpage.rst >> index 1cc0bc78d10e..afc8888f33c3 100644 >> --- a/Documentation/admin-guide/mm/hugetlbpage.rst >> +++ b/Documentation/admin-guide/mm/hugetlbpage.rst >> @@ -100,6 +100,32 @@ with a huge page size selection parameter "hugepagesz=". must >> be specified in bytes with optional scale suffix [kKmMgG]. The default huge >> page size may be selected with the "default_hugepagesz=" boot parameter. >> >> +Hugetlb boot command line parameter semantics >> +hugepagesz - Specify a huge page size. Used in conjunction with hugepages >> + parameter to preallocate a number of huge pages of the specified >> + size. Hence, hugepagesz and hugepages are typically specified in >> + pairs such as: >> + hugepagesz=2M hugepages=512 >> + hugepagesz can only be specified once on the command line for a >> + specific huge page size. Valid huge page sizes are architecture >> + dependent. >> +hugepages - Specify the number of huge pages to preallocate. This typically >> + follows a valid hugepagesz parameter. However, if hugepages is the >> + first or only hugetlb command line parameter it specifies the number >> + of huge pages of default size to allocate. The number of huge pages >> + of default size specified in this manner can be overwritten by a >> + hugepagesz,hugepages parameter pair for the default size. >> + For example, on an architecture with 2M default huge page size: >> + hugepages=256 hugepagesz=2M hugepages=512 >> + will result in 512 2M huge pages being allocated. If a hugepages >> + parameter is preceded by an invalid hugepagesz parameter, it will >> + be ignored. >> +default_hugepagesz - Specify the default huge page size. This parameter can >> + only be specified on the command line. No other hugetlb command line >> + parameter is associated with default_hugepagesz. Therefore, it can >> + appear anywhere on the command line. Valid default huge page size is >> + architecture dependent. > > Maybe specify what happens/should happen in a case like: > > hugepages=100 default_hugepagesz=1G > > Does that allocate 100 2MB pages or 100 1G pages? Assuming the default > size is 2MB. > > Also, regarding Randy's comment. It may be nice to keep these docs in > one place only, so we don't have to maintain 2 docs in sync. > > >> + >> When multiple huge page sizes are supported, ``/proc/sys/vm/nr_hugepages`` >> indicates the current number of pre-allocated huge pages of the default size. >> Thus, one can use the following command to dynamically allocate/deallocate >> diff --git a/mm/hugetlb.c b/mm/hugetlb.c >> index cc85b4f156ca..2b9bf01db2b6 100644 >> --- a/mm/hugetlb.c >> +++ b/mm/hugetlb.c >> @@ -2954,7 +2954,7 @@ static void __init hugetlb_sysfs_init(void) >> err = hugetlb_sysfs_add_hstate(h, hugepages_kobj, >> hstate_kobjs, &hstate_attr_group); >> if (err) >> - pr_err("Hugetlb: Unable to add hstate %s", h->name); >> + pr_err("HugeTLB: Unable to add hstate %s", h->name); >> } >> } >> >> @@ -3058,7 +3058,7 @@ static void hugetlb_register_node(struct node *node) >> nhs->hstate_kobjs, >> &per_node_hstate_attr_group); >> if (err) { >> - pr_err("Hugetlb: Unable to add hstate %s for node %d\n", >> + pr_err("HugeTLB: Unable to add hstate %s for node %d\n", >> h->name, node->dev.id); >> hugetlb_unregister_node(node); >> break; >> @@ -3109,19 +3109,35 @@ static int __init hugetlb_init(void) >> if (!hugepages_supported()) >> return 0; >> >> - if (!size_to_hstate(default_hstate_size)) { >> - if (default_hstate_size != 0) { >> - pr_err("HugeTLB: unsupported default_hugepagesz %lu. Reverting to %lu\n", >> - default_hstate_size, HPAGE_SIZE); >> - } >> - >> + /* >> + * Make sure HPAGE_SIZE (HUGETLB_PAGE_ORDER) hstate exists. Some >> + * architectures depend on setup being done here. >> + * >> + * If a valid default huge page size was specified on the command line, >> + * add associated hstate if necessary. If not, set default_hstate_size >> + * to default size. default_hstate_idx is used at runtime to identify >> + * the default huge page size/hstate. >> + */ >> + hugetlb_add_hstate(HUGETLB_PAGE_ORDER); >> + if (default_hstate_size) >> + hugetlb_add_hstate(ilog2(default_hstate_size) - PAGE_SHIFT); >> + else >> default_hstate_size = HPAGE_SIZE; >> - hugetlb_add_hstate(HUGETLB_PAGE_ORDER); >> - } >> default_hstate_idx = hstate_index(size_to_hstate(default_hstate_size)); >> + >> + /* >> + * default_hstate_max_huge_pages != 0 indicates a count (hugepages=) >> + * specified before a size (hugepagesz=). Use this count for the >> + * default huge page size, unless a specific value was specified for >> + * this size in a hugepagesz/hugepages pair. >> + */ >> if (default_hstate_max_huge_pages) { >> if (!default_hstate.max_huge_pages) >> - default_hstate.max_huge_pages = default_hstate_max_huge_pages; >> + default_hstate.max_huge_pages = >> + default_hstate_max_huge_pages; >> + else >> + pr_warn("HugeTLB: First hugepages=%lu kB ignored\n", >> + default_hstate_max_huge_pages); >> } >> >> hugetlb_init_hstates(); >> @@ -3174,20 +3190,27 @@ void __init hugetlb_add_hstate(unsigned int order) >> parsed_hstate = h; >> } >> >> -static int __init hugetlb_nrpages_setup(char *s) >> +/* >> + * hugepages command line processing >> + * hugepages must normally follows a valid hugepagsz specification. If not, > > 'hugepages must' or 'hugepages normally follows' >> + * ignore the hugepages value. hugepages can also be the first huge page >> + * command line option in which case it specifies the number of huge pages >> + * for the default size. >> + */ >> +static int __init hugepages_setup(char *s) >> { >> unsigned long *mhp; >> static unsigned long *last_mhp; >> >> if (!parsed_valid_hugepagesz) { >> - pr_warn("hugepages = %s preceded by " >> + pr_warn("HugeTLB: hugepages = %s preceded by " >> "an unsupported hugepagesz, ignoring\n", s); >> parsed_valid_hugepagesz = true; >> return 1; >> } >> /* >> - * !hugetlb_max_hstate means we haven't parsed a hugepagesz= parameter yet, >> - * so this hugepages= parameter goes to the "default hstate". >> + * !hugetlb_max_hstate means we haven't parsed a hugepagesz= parameter >> + * yet, so this hugepages= parameter goes to the "default hstate". >> */ >> else if (!hugetlb_max_hstate) >> mhp = &default_hstate_max_huge_pages; > > We don't set parsed_valid_hugepagesz to false at the end of this > function, shouldn't we? Parsing a hugepages= value should 'consume' a > previously defined hugepagesz= value, so that this is invalid IIUC: > > hugepagesz=x hugepages=z hugepages=y > In this case, we'll get: "HugeTLB: hugepages= specified twice without interleaving hugepagesz=, ignoring hugepages=y" >> @@ -3195,7 +3218,8 @@ static int __init hugetlb_nrpages_setup(char *s) >> mhp = &parsed_hstate->max_huge_pages; >> >> if (mhp == last_mhp) { >> - pr_warn("hugepages= specified twice without interleaving hugepagesz=, ignoring\n"); >> + pr_warn("HugeTLB: hugepages= specified twice without interleaving hugepagesz=, ignoring hugepages=%s\n", >> + s); >> return 1; >> } >> >> @@ -3214,8 +3238,15 @@ static int __init hugetlb_nrpages_setup(char *s) >> >> return 1; >> } >> -__setup("hugepages=", hugetlb_nrpages_setup); >> +__setup("hugepages=", hugepages_setup); >> >> +/* >> + * hugepagesz command line processing >> + * A specific huge page size can only be specified once with hugepagesz. >> + * hugepagesz is followed by hugepages on the commnad line. The global >> + * variable 'parsed_valid_hugepagesz' is used to determine if prior >> + * hugepagesz argument was valid. >> + */ >> static int __init hugepagesz_setup(char *s) >> { >> unsigned long long size; >> @@ -3230,16 +3261,23 @@ static int __init hugepagesz_setup(char *s) >> } >> >> if (size_to_hstate(size)) { >> + parsed_valid_hugepagesz = false; >> pr_warn("HugeTLB: hugepagesz %s specified twice, ignoring\n", >> saved_s); >> return 0; >> } >> >> + parsed_valid_hugepagesz = true; >> hugetlb_add_hstate(ilog2(size) - PAGE_SHIFT); >> return 1; >> } >> __setup("hugepagesz=", hugepagesz_setup); >> >> +/* >> + * default_hugepagesz command line input >> + * Only one instance of default_hugepagesz allowed on command line. Do not >> + * add hstate here as that will confuse hugepagesz/hugepages processing. >> + */ >> static int __init default_hugepagesz_setup(char *s) >> { >> unsigned long long size; >> @@ -3252,6 +3290,12 @@ static int __init default_hugepagesz_setup(char *s) >> return 0; >> } >> >> + if (default_hstate_size) { >> + pr_err("HugeTLB: default_hugepagesz previously specified, ignoring %s\n", >> + saved_s); >> + return 0; >> + } >> + >> default_hstate_size = size; >> return 1; >> } >> -- >> 2.24.1 >> >> > . > --- Regards, Longpeng(Mike) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel