From patchwork Sun Aug 6 07:48:50 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Xueshi Hu X-Patchwork-Id: 13342741 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 78B3DC04A6A for ; Sun, 6 Aug 2023 07:49:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 952C78D0003; Sun, 6 Aug 2023 03:49:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 902488D0001; Sun, 6 Aug 2023 03:49:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7A2DB8D0003; Sun, 6 Aug 2023 03:49:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 6815E8D0001 for ; Sun, 6 Aug 2023 03:49:49 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 3C9621403D5 for ; Sun, 6 Aug 2023 07:49:49 +0000 (UTC) X-FDA: 81092905698.19.1F66A2B Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) by imf17.hostedemail.com (Postfix) with ESMTP id 5720E40003 for ; Sun, 6 Aug 2023 07:49:47 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=smartx-com.20221208.gappssmtp.com header.s=20221208 header.b=3g2HK9xu; dmarc=none; spf=none (imf17.hostedemail.com: domain of xueshi.hu@smartx.com has no SPF policy when checking 209.85.214.170) smtp.mailfrom=xueshi.hu@smartx.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1691308187; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=sZAexKHlTLbku9ZRzqfarX+iplWFNaqld5PNMMj/Qvw=; b=FSW5V8QhNYDhjsFoYnlo67zyMlReQFGZpPNw1sXMPXb1q7CDS90EAKErebcskKvoUyPpFp ei6B0J7QsNM/yocnu5Cg6jr0DJ74YsHRKdriIjVn+QZX9o06aoOSi1pWfx8Ziu3FmAP60c OjULw+Nyg++8bEHMBnn43gxkEfRX3mc= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=smartx-com.20221208.gappssmtp.com header.s=20221208 header.b=3g2HK9xu; dmarc=none; spf=none (imf17.hostedemail.com: domain of xueshi.hu@smartx.com has no SPF policy when checking 209.85.214.170) smtp.mailfrom=xueshi.hu@smartx.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691308187; a=rsa-sha256; cv=none; b=Ev0/uDcb8nXFVSfWBI74lwvYa19AFsyI27F8PlUieej8653Q55hCtCf1WJRk9E/ULxNnl0 dadIeQPPwdi1KUNmAgL607ksoIofl5nV5GG3n8bioPTJd93KwQ/+ZjFU3o2ybCfkapBU79 NXyrkQ+04ZVkjMlozxkBEKWjY+WukrE= Received: by mail-pl1-f170.google.com with SMTP id d9443c01a7336-1bbf3da0ea9so22581835ad.2 for ; Sun, 06 Aug 2023 00:49:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smartx-com.20221208.gappssmtp.com; s=20221208; t=1691308186; x=1691912986; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=sZAexKHlTLbku9ZRzqfarX+iplWFNaqld5PNMMj/Qvw=; b=3g2HK9xu7Mia0uw4MMy4nkeafEFA9GfKerneg2vOB2gXC6wG9VAd2pNdwPxnRXlms2 Bsl6ilH2gT6H2P1ryY+DCbOGgm4Y0rlne7aQPkGhHGF5SX3jnfC66oi/xfpHNeNocOxE X13SQ7EJXi5wZm+4DpH3riu+TN/RwcOOu7wtEHjseq37MM+qrpkR1mrPsVmHOunOt33q v31pZOaSok3jrq5RiuD28S3TU3wRUgZiqpYQ9IW9T2s3S14E8PEYPhoQt3LfYoK4cEEW 0orXRmqulTqQGq8lKY6ifPfSAyReiAjYN5FNi9dyuWzutZ75uzHzUdMg8KzeZEcehPfg rGFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691308186; x=1691912986; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=sZAexKHlTLbku9ZRzqfarX+iplWFNaqld5PNMMj/Qvw=; b=LW0StJ/LdQ3zbYO73g6/G8GIxIZrW5Dy2GSGIOlYEKzDDASiOiHUIsMib8TfYZx3Gy vbK49ClhqcjyuTM5bMhv4xqIw+JfFeah/ZMzH9EVza2dMOYDmbNICBoF51MsewdiFJuZ Xte/4P/FXS+B0gKSU+MsxomaBS6+WrLaYUGixMr/gbCplY4bPEvVcYRyW21dCdXwVfbz C7KIBQV26sVPA7auNRa40AV8fNpQSWK+PZnPOw1tDw44E2qFTJPIB7lswbH5TwlhMDpO 3vLSK/SaZUxnKf11/QOTWvB5HBP6lDHRcAlXA/r/LG/phbLi4rrnDXKfbSje2mQkLDe1 UKWQ== X-Gm-Message-State: AOJu0YzNuKNjxqM3JWCx6epUh2lr1GDFXMQ2Ju8VnbZyx2JWbx2+xd0+ 2i7KjB/AqQME0HfE8BV4Zx8PDw== X-Google-Smtp-Source: AGHT+IE3at5REpPLiM9+2UvSg4eadK0wJ5motjJssu3wVjtzJARJ0udPZZlZ88MAqkMRZpQZ2QDyzQ== X-Received: by 2002:a17:902:db04:b0:1b6:8a99:4979 with SMTP id m4-20020a170902db0400b001b68a994979mr6459599plx.22.1691308186175; Sun, 06 Aug 2023 00:49:46 -0700 (PDT) Received: from nixos.tailf4e9e.ts.net ([47.75.78.161]) by smtp.googlemail.com with ESMTPSA id j3-20020a170902c3c300b001b9cf6342e2sm4522814plj.42.2023.08.06.00.49.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 06 Aug 2023 00:49:45 -0700 (PDT) From: Xueshi Hu To: mike.kravetz@oracle.com, muchun.song@linux.dev, corbet@lwn.net, akpm@linux-foundation.org, n-horiguchi@ah.jp.nec.com, osalvador@suse.de Cc: linux-mm@kvack.org, Xueshi Hu Subject: [PATCH v2 1/4] mm/hugetlb: fix the inconsistency of /proc/sys/vm/nr_huge_pages Date: Sun, 6 Aug 2023 15:48:50 +0800 Message-Id: <20230806074853.317203-2-xueshi.hu@smartx.com> X-Mailer: git-send-email 2.40.1 In-Reply-To: <20230806074853.317203-1-xueshi.hu@smartx.com> References: <20230806074853.317203-1-xueshi.hu@smartx.com> MIME-Version: 1.0 X-Rspamd-Queue-Id: 5720E40003 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 6oy7niwyxw73rxnywt3rcbdmod8noqpt X-HE-Tag: 1691308187-569446 X-HE-Meta: U2FsdGVkX19pEbGiqlsruZNZ/TaprLoLMkOelsOYTG2RON8VhvhEVltGpeJL1tbmbHRDAw9jsayBJ/bCK3N0pleYqgNdGBGrApp97W7YWxLsFup0+6Th6IYw2g8O2SctDrF+dXE/pfnu4FwGJtu6b/JvFi4kSrhzATSQp5PDN+lHRhw+ygucuGvaJof7O4+DdGIajWtTxtASwBufJHa547yI+SuzOHp3LnZP6f37M8P5vogm9FKlKz9L77yFaN/pm1eqgCckDCUlObzNfiq6S9zVK7W3BcoQrRVudykDuznsJGZE6wQcwKEVxWyZs+6il81W4HGQz9ihhwSzW8UQhnfo5kKtc/sW8zMeUXNv5O2se/fLDLLTmX2nuulkmjQTxxcpvPmxM8tf0YcWflDzdKadADc5iW73Pp6cK1Z+ayOTQwg6BxMCbFmgxignThYiM0ZGW/90q89JtmeRcWaclTBIoZahFxvMqyrvBktQNzUCLzhKpg4CjGnn+yObv7NN2muiev5xeyE4F5T7Miarg68hkrKs0wbFCilLcAWfDLPExJSrX512HkqgGVzFuDYPVDF1MHpxOBdRdVr5639YzC+LaGsYQfcPw5a8njpx+NaUO5606z8rG5lSC5hxIqepw4INC2LgHuoadSjnYyYz4z2p3Jgsia0mQf14aaaGPTzkINTN3F8NhOXaNXHqkTZQ7E6xrnaZDhmpSgXBSNhrqfGHxVwPy//RCPHepXyio4gmi32kTHhnBekogy7IHgl+oSbfL/cyPcaR5hkeskgVT6zM0wOkoIKzF8u4vySa4DsU5IyrCUKAn4lH3JXHDUAA/jPoLP8qc0OvHRIxBh99rL9fad2O/5cW/5yuJg7Wl5cNc3QxCwiqK6+VarnK871i0sLyiRO/gKpx3xEgynmH/jH8HNDpaVgyG220CyYRJ/8WCqLWsmuQHqplNYCghrZrHen9MQY+4/rCcJHfpSe HJn5W1t+ pFaikZrGSXBdTTa/RLFnWndJM/0nGBe3i5vnzmb92C/eCk2JttkD+esZjK9XH4EJuAqdHubIUhk7PK2NGA/6sP5P91A4Eq/AnGcv+K7O+jpAaOdeK4wncuPjV/CROnOj2T3qTTgCgcrfgBxcHRxoddSJRX0fA3QAnt4F5eigLvlj6UVH+vkfXqt/2myA0FDKTwC/S2QsQMCim7EVhyA91v7cPhwP49O0+81j3NPP9o3uXbkIUc0kpFACV0vLFMoj4N09pSQ4l4S05lOv1eVZJWhpvRg3OT5QWyVoe0cXxEojBBf8czFV/rAcZcerkERDGNqjAEui7BWp/y2yRBWpgSM4QV1QW1wfU62rJ+2HZhI7ud09wb+phuNPWE+oks/2eQicOfsK579OG9rDeoZ1YxXBGzzXqSmbEqACxmOxVi1fw2nlCY+LMVeUACeknDRyxx2cbuXyj/uek8vCB5p7YK3n2PA== 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: There are currently three 'nr_hugepages' used to export the number of huge pages: 1. /proc/sys/vm/nr_hugepages 2. /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages 3. /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages For consistency, all three 'nr_hugepages' should return the total number of huge pages. When written, the number of persistent huge pages will be adjusted to the specified value. But, /proc/sys/vm/nr_hugepages returns the number of persistent huge pages. Signed-off-by: Xueshi Hu --- mm/hugetlb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index e327a5a7602c..76af189053f0 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -4606,7 +4606,7 @@ static int hugetlb_sysctl_handler_common(bool obey_mempolicy, void *buffer, size_t *length, loff_t *ppos) { struct hstate *h = &default_hstate; - unsigned long tmp = h->max_huge_pages; + unsigned long tmp = h->nr_huge_pages; int ret; if (!hugepages_supported()) From patchwork Sun Aug 6 07:48:51 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Xueshi Hu X-Patchwork-Id: 13342742 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 367B6C001DE for ; Sun, 6 Aug 2023 07:49:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A68AF8D0006; Sun, 6 Aug 2023 03:49:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A13648D0005; Sun, 6 Aug 2023 03:49:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8BBB68D0006; Sun, 6 Aug 2023 03:49:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 6E2F88D0005 for ; Sun, 6 Aug 2023 03:49:52 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 409B6B1DA5 for ; Sun, 6 Aug 2023 07:49:52 +0000 (UTC) X-FDA: 81092905824.06.56E3526 Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) by imf20.hostedemail.com (Postfix) with ESMTP id 636A91C0019 for ; Sun, 6 Aug 2023 07:49:50 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=smartx-com.20221208.gappssmtp.com header.s=20221208 header.b=qKtVZaAS; spf=none (imf20.hostedemail.com: domain of xueshi.hu@smartx.com has no SPF policy when checking 209.85.214.179) smtp.mailfrom=xueshi.hu@smartx.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1691308190; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=IWO97P41pTgDcE9XlJTPRLerxITDufaXqvlZ/NpQ9xw=; b=8C27DpZUc3Z7Sa2sknC4+BaojnROzgz0XFIUslIPHCTtsJiIPbapWQreAS401WYlWspP4v 1e3dPNFnrqTmSxwLBOtAz6OhEJsMfEDMvOYJ4RG0dF3K8BbrFoxw+79aLJlAkymkeMO53Q qZjyjJEmiw3QLDzCv0PHojQM8BhsArs= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=smartx-com.20221208.gappssmtp.com header.s=20221208 header.b=qKtVZaAS; spf=none (imf20.hostedemail.com: domain of xueshi.hu@smartx.com has no SPF policy when checking 209.85.214.179) smtp.mailfrom=xueshi.hu@smartx.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691308190; a=rsa-sha256; cv=none; b=su0j6ZqzNEh3HkZHF3cCWwkuAS94zmI1u/lrDEwqktJn+2NEUVwUiCQESD2bYcVZzuu1Yd VWXoVa1IN2+seNJtBE+HPhuLM3IqzyfzNrhKvRg3NAzWa1LiJI9WcCrtV9oi7l3jeD59+E ktgEf7ZKKWxPgGdf43vaeG9d/35gRek= Received: by mail-pl1-f179.google.com with SMTP id d9443c01a7336-1bc3d94d40fso31025145ad.3 for ; Sun, 06 Aug 2023 00:49:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smartx-com.20221208.gappssmtp.com; s=20221208; t=1691308189; x=1691912989; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=IWO97P41pTgDcE9XlJTPRLerxITDufaXqvlZ/NpQ9xw=; b=qKtVZaASZvHdsOrl0UvxpHJViBZrzscbST/b3CtYMT3XVWYE4+QgnGMDDoFUn7WRiN aCaSeEcacve4eUjxb2goCsR73RKWuMDSexbUccnuKcswovdl0VhcDzoZbY4tiPnf6z/4 ZYVnfg2kMRi0tq326Vpkkw9GTzheiCRRMk4A+D9qC87xN3RKgLyCem4sFmEkxlqIUiPB AJpop2T1r6YCHlSquGkH5270M6kejXB7DD7r9GxcyCgfsZxOTgvuvsZadt+hqf8llmh4 iqiz+4Dj+eT0pcaxhVjpbsadZ10h6R2MbGHOy412TmXSy6uT9dvjL9/VeJtdObw97LQK OIBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691308189; x=1691912989; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=IWO97P41pTgDcE9XlJTPRLerxITDufaXqvlZ/NpQ9xw=; b=dhSdBd9wbz3Wty2uQsuER+3ZxkTbW1QpldpHoxLp+qu9wn9gRvkVJGeEFPQsLHSsyO fuWrOWK7+pr3TuYMlC3IgnPWCrW7aqSzXrUYoUUU9NkwSW3pLF/pBB5y1XShn07ORZ4V er1vj7h1URrLF8GP4ELx7LVDQOseSyd1Cr3lYTMIFlX9OvXJLsAFCdHhubx+UN7qV4ag 1ZPiv0Rz23QQrSxJ+L+ijt67r9gHcqwXS6aXvdQG+9A303WW2TwAZvZvmaXwA8eGmkxa 7rytTYGVNz5Zb9LceEY9WxoUMdGbIb8KUkcnvMGXUkSR204dAk2PVShXGbM6/5w4O3WT eIJg== X-Gm-Message-State: AOJu0YyAMUZBEz2Ymk+Lr6fSyU0WmF6xUbZR5WqH3m2kjHDeurL5NWLE XuMkfK7ldiVo54Hf1LvVM38jQg== X-Google-Smtp-Source: AGHT+IEMSjDu3fkUxq4yLpKnI9NOXYrwPFZ+a1WrGPLSdJlWaOwcYOqco4fDD3ILzMQiRTh4fCldzA== X-Received: by 2002:a17:903:2351:b0:1bb:a85c:23cc with SMTP id c17-20020a170903235100b001bba85c23ccmr7867280plh.15.1691308188827; Sun, 06 Aug 2023 00:49:48 -0700 (PDT) Received: from nixos.tailf4e9e.ts.net ([47.75.78.161]) by smtp.googlemail.com with ESMTPSA id j3-20020a170902c3c300b001b9cf6342e2sm4522814plj.42.2023.08.06.00.49.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 06 Aug 2023 00:49:48 -0700 (PDT) From: Xueshi Hu To: mike.kravetz@oracle.com, muchun.song@linux.dev, corbet@lwn.net, akpm@linux-foundation.org, n-horiguchi@ah.jp.nec.com, osalvador@suse.de Cc: linux-mm@kvack.org, Xueshi Hu Subject: [PATCH v2 2/4] mm/hugeltb: clean up hstate::max_huge_pages Date: Sun, 6 Aug 2023 15:48:51 +0800 Message-Id: <20230806074853.317203-3-xueshi.hu@smartx.com> X-Mailer: git-send-email 2.40.1 In-Reply-To: <20230806074853.317203-1-xueshi.hu@smartx.com> References: <20230806074853.317203-1-xueshi.hu@smartx.com> MIME-Version: 1.0 X-Rspamd-Queue-Id: 636A91C0019 X-Rspam-User: X-Stat-Signature: 8sp34wfxu1yrtwof54beumeo9oegjn5h X-Rspamd-Server: rspam01 X-HE-Tag: 1691308190-542316 X-HE-Meta: U2FsdGVkX1+hEoDl0P0XwvqjyITfm3ODbDEn80GY+BLS2rgfj0lJB51kDlikPzwPvfFQo2r23YDcfCuH49/t6qhgBTnEIXr33eKI3nI0kAG8e8N3i5rEYdUaFgaU40BZ3CMpnsEJQEEDcRrH3+MyDKVYNs9MeUQ22GfBFMQNYxwwl5e43I3k+YpBzaygsRy5slnFGbBZfd8bb+ALQipfb9nmIiA/K1/r/lQMPLVdvg959Hxqk92zkaJMgcC6E9PHxC1duB5ByCVZDkjRtIKceT4UaqnFeMG/QYwDJmr0DLiOcT1DDsL3t4sArb+y0zuQYQ4XlhKI+/GHgms1bZTZyCiFaD6PGMVzIUwMmbjEmHjw6JmLXmPcF/gAvSUn7sG7dVrMNRXlIpPkxqrPFWr5LfiliPCwnduJneq7Mtp6P8XHZoSFNjjuT4K8FscS99/o8kyXuNuxCVwaWT0zPyaSlJjTCRkFGuy/OO18TQd0/yImfV08984i2dehEeqemEbwMAwRQz3AOE1V6ud3WGoWGfA/S0m1PiTKyZoa/uEDrT0torJO4rpVjHRn1GgMiYXiKIcMk5NAp7CvCXPHIJIBAbA7+yHskzAKL2AhZRSRtB9I+7F/ZHsE9BMZgOJPaROjGUjDSdWtnlCtruzl0lb3rylfQ/ku/4siLH+tp/5bae9L5p3gPquUZ9sDBcEDORi5YQZ70oGuNQu7UGpJZELGwRK9lvSk4Y+uwVmTN89Jw22CX00LA0H4koF3on1v3Hyifodx5W5keJjNHZTxOUVXA8ACYQ2FK81S4cuLZNNEIktoqwrVpx7etXBj24LpBMQXq18vqOPk44GWip4xIBGjXaZ0agn19yTGFgMYff8GhXDLXQXspYRK+GmuY/cLc6/0+ghueTJ/L6kCq/bh3u5+z243BI/rq9m64O73aVrOuk3noG8IEtMHOHcYnaQAtXM4FzszJgmqmshTmyLHhU+ J5XHU3L0 xJzUlLkVLOYfwzdx1x77u3G8OYVX2g11Qevw6zcxQhx7k0DCu0VYm+ioIcPfEsDtZ9z7nvjcaAHGSjr9+rwgCP2ZT/4wp64FrbZKEzrl7a9pTIL+GIdumaxAxaqOFwYKqjv9YuIeJ2bxCp+pubWQZcb6HJuxfrXTbg41VxqunuK6eZEzjExc2mwAD4Ebunwymc6apk0J/U5QggovQ4qEDSjFvckABqMAHngYA6ONlDKkljtosKhAaee4BxZd5OL822/xCxH9Gr5yLG73D6LMMD3MCSEvbskON8elDEmXJYWP5ySssOpdRHFBKoxRA/O85QSuy+GrgpoOaG7TJpOaTO9suY4L4Sr9hdvxdPTcFnkIYTBCS+JEzcEhtMjOFSgosarSkYhs4paX4VN8LBuJB7RH7wGSJKdNluXQpEPg5Q3PaKfhXzZaizRMwX2YkQc+rRlHITN2mA1nOImIKfHl+g42oow== 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: Presently, the sole use case of hstate::max_huge_pages is confined to hugetlb_sysctl_handler_common() and hugetlbfs_size_to_hpages(). The former has been replaced with hstate::nr_huge_pages, while the latter can be effortlessly substituted. After hugeltb subsystem has been initialized, hstate::max_huge_pages always equals to persistent_huge_pages(). It's a burden to maintain the equation[1][2]. After this patch, hstate::max_huge_pages is only used in kernel command line parameter parsing. Renaming set_max_huge_pages() to set_nr_huge_pages() would enhance the readability of the code. [1]: Commit a43a83c79b4f ("mm/hugetlb: fix incorrect update of max_huge_pages") [2]: Commit c1470b33bb6e ("mm/hugetlb: fix incorrect hugepages count during mem hotplug") Signed-off-by: Xueshi Hu --- fs/hugetlbfs/inode.c | 2 +- mm/hugetlb.c | 24 +++++------------------- 2 files changed, 6 insertions(+), 20 deletions(-) diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c index 316c4cebd3f3..cd1a3e4bf8fb 100644 --- a/fs/hugetlbfs/inode.c +++ b/fs/hugetlbfs/inode.c @@ -1375,7 +1375,7 @@ hugetlbfs_size_to_hpages(struct hstate *h, unsigned long long size_opt, if (val_type == SIZE_PERCENT) { size_opt <<= huge_page_shift(h); - size_opt *= h->max_huge_pages; + size_opt *= (h->nr_huge_pages - h->surplus_huge_pages); do_div(size_opt, 100); } diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 76af189053f0..56647235ab21 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -2343,14 +2343,13 @@ int dissolve_free_huge_page(struct page *page) } remove_hugetlb_folio(h, folio, false); - h->max_huge_pages--; spin_unlock_irq(&hugetlb_lock); /* * Normally update_and_free_hugtlb_folio will allocate required vmemmmap * before freeing the page. update_and_free_hugtlb_folio will fail to * free the page if it can not allocate required vmemmap. We - * need to adjust max_huge_pages if the page is not freed. + * need to adjust nr_huge_pages if the page is not freed. * Attempt to allocate vmemmmap here so that we can take * appropriate action on failure. */ @@ -2360,7 +2359,6 @@ int dissolve_free_huge_page(struct page *page) } else { spin_lock_irq(&hugetlb_lock); add_hugetlb_folio(h, folio, false); - h->max_huge_pages++; spin_unlock_irq(&hugetlb_lock); } @@ -3274,8 +3272,6 @@ static void __init hugetlb_hstate_alloc_pages_onenode(struct hstate *h, int nid) string_get_size(huge_page_size(h), 1, STRING_UNITS_2, buf, 32); pr_warn("HugeTLB: allocating %u of page size %s failed node%d. Only allocated %lu hugepages.\n", h->max_huge_pages_node[nid], buf, nid, i); - h->max_huge_pages -= (h->max_huge_pages_node[nid] - i); - h->max_huge_pages_node[nid] = i; } static void __init hugetlb_hstate_alloc_pages(struct hstate *h) @@ -3336,7 +3332,6 @@ static void __init hugetlb_hstate_alloc_pages(struct hstate *h) string_get_size(huge_page_size(h), 1, STRING_UNITS_2, buf, 32); pr_warn("HugeTLB: allocating %lu of page size %s failed. Only allocated %lu hugepages.\n", h->max_huge_pages, buf, i); - h->max_huge_pages = i; } kfree(node_alloc_noretry); } @@ -3460,7 +3455,7 @@ static int adjust_pool_surplus(struct hstate *h, nodemask_t *nodes_allowed, } #define persistent_huge_pages(h) (h->nr_huge_pages - h->surplus_huge_pages) -static int set_max_huge_pages(struct hstate *h, unsigned long count, int nid, +static int set_nr_huge_pages(struct hstate *h, unsigned long count, int nid, nodemask_t *nodes_allowed) { unsigned long min_count, ret; @@ -3601,7 +3596,6 @@ static int set_max_huge_pages(struct hstate *h, unsigned long count, int nid, break; } out: - h->max_huge_pages = persistent_huge_pages(h); spin_unlock_irq(&hugetlb_lock); mutex_unlock(&h->resize_lock); @@ -3639,7 +3633,7 @@ static int demote_free_hugetlb_folio(struct hstate *h, struct folio *folio) destroy_compound_hugetlb_folio_for_demote(folio, huge_page_order(h)); /* - * Taking target hstate mutex synchronizes with set_max_huge_pages. + * Taking target hstate mutex synchronizes with set_nr_huge_pages. * Without the mutex, pages added to target hstate could be marked * as surplus. * @@ -3664,14 +3658,6 @@ static int demote_free_hugetlb_folio(struct hstate *h, struct folio *folio) spin_lock_irq(&hugetlb_lock); - /* - * Not absolutely necessary, but for consistency update max_huge_pages - * based on pool changes for the demoted page. - */ - h->max_huge_pages--; - target_hstate->max_huge_pages += - pages_per_huge_page(h) / pages_per_huge_page(target_hstate); - return rc; } @@ -3770,13 +3756,13 @@ static ssize_t __nr_hugepages_store_common(bool obey_mempolicy, } else { /* * Node specific request. count adjustment happens in - * set_max_huge_pages() after acquiring hugetlb_lock. + * set_nr_huge_pages() after acquiring hugetlb_lock. */ init_nodemask_of_node(&nodes_allowed, nid); n_mask = &nodes_allowed; } - err = set_max_huge_pages(h, count, nid, n_mask); + err = set_nr_huge_pages(h, count, nid, n_mask); return err ? err : len; } From patchwork Sun Aug 6 07:48:52 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Xueshi Hu X-Patchwork-Id: 13342743 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2881EC001DE for ; Sun, 6 Aug 2023 07:49:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B4ED08D0008; Sun, 6 Aug 2023 03:49:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AFD6B8D0009; Sun, 6 Aug 2023 03:49:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 950BA8D0008; Sun, 6 Aug 2023 03:49:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 7E9188D0007 for ; Sun, 6 Aug 2023 03:49:57 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 462411C94E3 for ; Sun, 6 Aug 2023 07:49:57 +0000 (UTC) X-FDA: 81092906034.05.7200AC6 Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) by imf17.hostedemail.com (Postfix) with ESMTP id 68EC040003 for ; Sun, 6 Aug 2023 07:49:55 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=smartx-com.20221208.gappssmtp.com header.s=20221208 header.b=j0mUyk86; dmarc=none; spf=none (imf17.hostedemail.com: domain of xueshi.hu@smartx.com has no SPF policy when checking 209.85.214.175) smtp.mailfrom=xueshi.hu@smartx.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691308195; a=rsa-sha256; cv=none; b=147RMscJEMlsjTV/miu3vsGtXzER9rXd1ClHm0/TnoMsZFOjYAVIYbB1tNCpuEunZbktIQ 0z7eH8MzOH8k5Yw9ssqeM5PI4+SMCIDjdFSJn94UGElRefZV2WDX4CcJUEMTIUDLrKwhOU oyLl6M8fSMCleTRB5iljKpIDWe0nzLI= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=smartx-com.20221208.gappssmtp.com header.s=20221208 header.b=j0mUyk86; dmarc=none; spf=none (imf17.hostedemail.com: domain of xueshi.hu@smartx.com has no SPF policy when checking 209.85.214.175) smtp.mailfrom=xueshi.hu@smartx.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1691308195; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=bESDgBeC8VG0WeABkpzPbNx9S1dNl6w+TJhQUnJNvuY=; b=uKLxRMAVfgKLTTIpwwk4F47e63ipV2+FmiAUEVFQO6fdXeSo4b2vpXAKSOG0oPLoJgnwnV cW5fpMaesSb+PVCONZSQwgb2I6aKP3lj+VrMPd33iNR7IFTaRwZ60a5djAfYiBACxOu6Wv Qv9AZgndxKVOVpkgABYEDn+fp1qEUQE= Received: by mail-pl1-f175.google.com with SMTP id d9443c01a7336-1bbf8cb694aso30800095ad.3 for ; Sun, 06 Aug 2023 00:49:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smartx-com.20221208.gappssmtp.com; s=20221208; t=1691308192; x=1691912992; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=bESDgBeC8VG0WeABkpzPbNx9S1dNl6w+TJhQUnJNvuY=; b=j0mUyk86Y+L0W/lPLGWO37sgMvzxFyNFnvPHdTcucxp6ExmGz1vgaKFhDgicf4eALX CcboTXVoB9YdanrWD1af/Ym+GRswuhYI/jtC3P7pBetKMbUD8Hr8j1oV2VSMxZWSqZaJ kj9mk6gysUCccc3YDRdLFv0sCXUw+1elkGdGh3CMxnbv8ohhDY7alr9SExXijyWXjS0o vMNI9bHLj3fKRsc1HEp9SSiCl/dkWp45Kpl3nQC4YiI6PO48NMpzJ8Vk4jAbVOCXCUzs Ke0m1yVTSr3aJnL9BR5Ef7S4tO9qjLwOS8/iFW4Npovb6ryu1KiRFf30DBqdk4+1cWG0 sxOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691308192; x=1691912992; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=bESDgBeC8VG0WeABkpzPbNx9S1dNl6w+TJhQUnJNvuY=; b=gmhYfwA9+z9NaO86j5wCmQDlnM/BZyR7Vk6sCDHp3H3mClX7LVHD9ECl620tqAo0hK 3rPXl+XcclifaQ7AWY20HtQyG9dxWuhaKQCBLMaj6jI5hFdRitZ3jJbXXpL4JT2DgdlP n/I2szxuaadPbSmOk8AV+0bXPq+bgGNwxmYwG0p4LxWtfrP3UJqa64P70Zcj6xO11wcj XHIxHcYXF8PGmUyqHeVsoxkk4YqEMgydL+bmB24R4hyWN4zZNZZo4qs127h6EA7u/nJO wbv3dJ6cTF4ThuPmqCOwuEoL5pQfqOICr+HEbI3dsApjuw0DevnO33ckPKFgMI80JCzw HgJQ== X-Gm-Message-State: AOJu0YwKiRSekH2SaSvsz1PygOaPYkisBv1BFCnsaO1XrPNYPHteFjWt FBNmWhkw3+QZU0K8su9GkvAWC5TtFcZ3w5i7g/UmDJ2adTs= X-Google-Smtp-Source: AGHT+IEORQqGLZlvviHoT0yKvywDKwgrGqlwgBU1COFRxeX6Xw7TdwQ7hJ+pw+m//1yv/KCVzgReQw== X-Received: by 2002:a17:902:8b84:b0:1b8:72e2:c63 with SMTP id ay4-20020a1709028b8400b001b872e20c63mr6670457plb.8.1691308191700; Sun, 06 Aug 2023 00:49:51 -0700 (PDT) Received: from nixos.tailf4e9e.ts.net ([47.75.78.161]) by smtp.googlemail.com with ESMTPSA id j3-20020a170902c3c300b001b9cf6342e2sm4522814plj.42.2023.08.06.00.49.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 06 Aug 2023 00:49:51 -0700 (PDT) From: Xueshi Hu To: mike.kravetz@oracle.com, muchun.song@linux.dev, corbet@lwn.net, akpm@linux-foundation.org, n-horiguchi@ah.jp.nec.com, osalvador@suse.de Cc: linux-mm@kvack.org, Xueshi Hu Subject: [PATCH v2 3/4] mm/hugeltb: fix nodes huge page allocation when there are surplus pages Date: Sun, 6 Aug 2023 15:48:52 +0800 Message-Id: <20230806074853.317203-4-xueshi.hu@smartx.com> X-Mailer: git-send-email 2.40.1 In-Reply-To: <20230806074853.317203-1-xueshi.hu@smartx.com> References: <20230806074853.317203-1-xueshi.hu@smartx.com> MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 68EC040003 X-Stat-Signature: 9ab9c6aigkf6ud7xuo8rpx5wtwr93hf5 X-HE-Tag: 1691308195-514577 X-HE-Meta: U2FsdGVkX19QCtB3Ocnl7RpcoprPpkN7nBE3eHIpwkZ0fYzKnVHneGvPVIQRs5JbBPVxZICki0D3i5EMt7aX4+3YTBVBJ2U29tOLMo8UxPzDkD9+o7L52/oh3nls4/gjflirRulP5ddsanb89UeIL0nhOLr+tPxaE62oYuDaAWutUkBZ+1COzbxR/zh9LQzY/4JWaNCA6r8pK5YiHnFi/CCmx0rGQUUfmQn6y4mJAwOYeTYsoYtuk3ALQecFPSHKzgvtWuip7kd92YBovE1fiFXrmBwySV0oB13L0CAFlBqpvzkXIGUYi0qkLpCp9O7DFVYFFWl8Gq6fcRINGT6idFUbps9VzSixqAI9z0Mmt1RZVKwtcZ0TcqbMYgt+MOoZBhv9ChUY6F+RBJlJmXOl7T8CGZ1qqFzwjlDwKOgedxZAfGVm5ZWjSmjjrk9Ny+sccTvdiHvogY6aVdjTuuinTcslQ7HcoTRJp9csWoQCy6tHsPPFfzAGTJNHLzGOYaqE9Ms1j7HjN2QwITj7NpNn5f8KlP83SEEmhiUSklEQ8tKAU3AVLaagpZ97pTOSp8+abMK5OqsN6cwgy5X/mPyZwjINE+MCSMfGb0f1EBiyy7XUoUhLEoj3flnhT0+oHB1q/m559b7tYN3dCa3yCZAcQMHPUfPe5KNnDD1Y1pZeR+1LybNDtsmZNZqGAj1m3upPxB1rXrVJ3TQY2bWw4RTRtZS3eG/P9voAxDN1bIaquvfbVADNoPFWxjzvj3PFbpEgCu/tQHKVT/0DWHkKEVbBbAyGgcAWjdh5hpP+jys4an+EqStljYOtvX5SPCdFvfUtPNcfOetqaq37cnPioHaRb6UZqOAp97OfvpqLWon6kcWgh24re32a5PL0K8J/QT7urHIK8I07V9n7T6d+JYiTmEwWFQlV9R2eF/qZlkpn1GhmdkUfhm63NlkyPz8nyFO0s/j4iOaUOcWy4qx7kU4 B1DzYr9N 3Yl8FuJ62SKloDENuUK4YojSHRDMfpghHJD1aGL74v9MWSts2yRLCQvqoQhe8xv0oHBRFWwxM3XEOYAw/yX2Bdq84UHpGtJvUpEcSnPAN328ceAYLokW1x9/lDTVv7r5iSTOMWwOJG+mr22Uh+L8/PKSR8VjmrIXaCTWJ/1qelkFt6vYZOT4CHsMrRGdfJgutKqPZRrdNFyBk7RxxOa86PhcY23I7nhOOeg3fFgwck3YHHJYhDiwZjmfHAKw43LGicSUzmZy0vqvByl8TV3CxkevRh1UnKdYXOXNUwAA6fU/JP2cUV2XnrQmiBXRUv5Sb3m/CGQXCq4o2xwkCp6e9KWypxGi8HMgQfy8rU5U1x8JRItBxtyuLHn4zPBSNIjqCb0SWTITEsNny8kmllErQrt8NRyTJm1gwo/DZVk/jsaYPWgI= 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: In set_nr_huge_pages(), local variable "count" is used to record persistent_huge_pages(), but when it cames to nodes huge page allocation, the semantics changes to nr_huge_pages. When there exists surplus huge pages and using the interface under /sys/devices/system/node/node*/hugepages to change huge page pool size, this difference can result in the allocation of an unexpected number of huge pages. Steps to reproduce the bug: Starting with: Node 0 Node 1 Total HugePages_Total 0.00 0.00 0.00 HugePages_Free 0.00 0.00 0.00 HugePages_Surp 0.00 0.00 0.00 create 100 huge pages in Node 0 and consume it, then set Node 0 's nr_hugepages to 0. yields: Node 0 Node 1 Total HugePages_Total 200.00 0.00 200.00 HugePages_Free 0.00 0.00 0.00 HugePages_Surp 200.00 0.00 200.00 write 100 to Node 1's nr_hugepages echo 100 > /sys/devices/system/node/node1/\ hugepages/hugepages-2048kB/nr_hugepages gets: Node 0 Node 1 Total HugePages_Total 200.00 400.00 600.00 HugePages_Free 0.00 400.00 400.00 HugePages_Surp 200.00 0.00 200.00 Kernel is expected to create only 100 huge pages and it gives 200. Fixes: fd875dca7c71 ("hugetlbfs: fix potential over/underflow setting node specific nr_hugepages") Signed-off-by: Xueshi Hu --- mm/hugetlb.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 56647235ab21..8ed4fffdebda 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -3490,7 +3490,9 @@ static int set_nr_huge_pages(struct hstate *h, unsigned long count, int nid, if (nid != NUMA_NO_NODE) { unsigned long old_count = count; - count += h->nr_huge_pages - h->nr_huge_pages_node[nid]; + count += persistent_huge_pages(h) - + (h->nr_huge_pages_node[nid] - + h->surplus_huge_pages_node[nid]); /* * User may have specified a large count value which caused the * above calculation to overflow. In this case, they wanted From patchwork Sun Aug 6 07:48:53 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Xueshi Hu X-Patchwork-Id: 13342744 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2C15AC00528 for ; Sun, 6 Aug 2023 07:50:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EA9F68D0007; Sun, 6 Aug 2023 03:49:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E59718D0009; Sun, 6 Aug 2023 03:49:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B4C108D0007; Sun, 6 Aug 2023 03:49:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 985A08D0007 for ; Sun, 6 Aug 2023 03:49:57 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 68439B1D00 for ; Sun, 6 Aug 2023 07:49:57 +0000 (UTC) X-FDA: 81092906034.28.BCA0EFF Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) by imf07.hostedemail.com (Postfix) with ESMTP id A60FD40003 for ; Sun, 6 Aug 2023 07:49:55 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=smartx-com.20221208.gappssmtp.com header.s=20221208 header.b=iV89qfci; spf=none (imf07.hostedemail.com: domain of xueshi.hu@smartx.com has no SPF policy when checking 209.85.214.182) smtp.mailfrom=xueshi.hu@smartx.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1691308195; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=g7ukv7uj/w5L1DuqNzfxmyygr180TVulkR/8ipJmp+k=; b=6NUI0AqX5y1liZrTFiXv/IRoIs6waQydtEspkGWuQ3jS+7pat01FGhUYZMTC1bRa6QIA5r dE/0QHwSRZOrgvsav8ZLwEuE1/0oHvQDtzk3umKyTVX3Foma4HGNYcrnv2cYJQoIM8PIGp /AaWcbmn4hXZWKqayP4NPxl5Kmw5Vgs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691308195; a=rsa-sha256; cv=none; b=w8BYpyFymNMHjXCwvpm61g4/NR90Xu0BIPzM4y6g2QBkDcqJuysAO9zG5ko4wJsU4Q0na0 iODe0i2g8asmNAI+mx88s+4D81lEnXkhiCuGIWtWp3WVP6XQeK/io9qu2jimj5PxjJmKZq FTt+UaaC2CpbGlQ+wIC12zyhwiVV+Uw= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=smartx-com.20221208.gappssmtp.com header.s=20221208 header.b=iV89qfci; spf=none (imf07.hostedemail.com: domain of xueshi.hu@smartx.com has no SPF policy when checking 209.85.214.182) smtp.mailfrom=xueshi.hu@smartx.com; dmarc=none Received: by mail-pl1-f182.google.com with SMTP id d9443c01a7336-1b8b2b60731so21532445ad.2 for ; Sun, 06 Aug 2023 00:49:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smartx-com.20221208.gappssmtp.com; s=20221208; t=1691308194; x=1691912994; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=g7ukv7uj/w5L1DuqNzfxmyygr180TVulkR/8ipJmp+k=; b=iV89qfcivx30bnrPidqV+sz8dB408ao/3ENbC1N6bI2l0QJR+YT/+1cX1vN+pozdYi BETlcmIm8BT/djSIEZ/EQkbv0UAh3Lysoya7v2QHY8W9F35Ulmcz/aSaOXLMr5SJ5JT7 tMXNQIKqQnPDTkDxV1JbdyHUUTk6uJOS+Hs6CLsO9lzXnUAvJzCsMxhAd6qW6S4REktS HaR/uucxRMnizZbNahn6Dr32mk0kj5MRdC5eXJ7tYxRj+vvvRvF01m9nKvvkUWhvVVIk TGl6w1lGYA6SssLtkXx8HnSu81Y027gjcKA5hbaYqIkLCdtLHzQczpWAiJxfEEymTObb 7WBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691308194; x=1691912994; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=g7ukv7uj/w5L1DuqNzfxmyygr180TVulkR/8ipJmp+k=; b=HA4d6lD2WLGR9ZT04OncsaWTfqN9fduYYha6yeTpTVggEViq/OsyG7hHIcC9TT8mnJ F9snVd+FP4d1SC76jA4L9zxgLsPhzGNVK8iW2FanVVEF/zosQ1w1ekM07qqje5Qn6NP5 VGn+B9hElrsPpw2/Z2WDmPpmu0c9x4Z8w5o5pA994XV3yUoqf0N7lSU7mHCL5YngU8MU 5hry8o+vYNJ4gzXkBLpxtRrix36rh0rP/L9FlvlNATVTX9yUeiLUPP5BdMZfZv+A9evw hkV239hQcQK5bITg52r418iclzV1IDAd3uipfpIN8Abs0IUdFpH6btohZPZ8oi79bvhr 6QzA== X-Gm-Message-State: AOJu0YySU1XoglZM8scq2CVoyhDbdQaE0BYRdwMfAn+RXw1GHLmVjsKq jmjgi6OrokVu23FuAnCZXZN1Lw98ZgHiPiiNvYc1Fe7I1ZE= X-Google-Smtp-Source: AGHT+IHxATCv/rO3OTpBId6jyTeTGK4oKIAByqysePNAn4BrejBAbZaw6UMgxcgwXeZXeXacgjMsFQ== X-Received: by 2002:a17:903:230b:b0:1bc:239:a7e3 with SMTP id d11-20020a170903230b00b001bc0239a7e3mr6387495plh.44.1691308194509; Sun, 06 Aug 2023 00:49:54 -0700 (PDT) Received: from nixos.tailf4e9e.ts.net ([47.75.78.161]) by smtp.googlemail.com with ESMTPSA id j3-20020a170902c3c300b001b9cf6342e2sm4522814plj.42.2023.08.06.00.49.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 06 Aug 2023 00:49:54 -0700 (PDT) From: Xueshi Hu To: mike.kravetz@oracle.com, muchun.song@linux.dev, corbet@lwn.net, akpm@linux-foundation.org, n-horiguchi@ah.jp.nec.com, osalvador@suse.de Cc: linux-mm@kvack.org, Xueshi Hu Subject: [PATCH v2 4/4] docs: hugetlbpage.rst: make the meaning of persistent hugetlb pages clear Date: Sun, 6 Aug 2023 15:48:53 +0800 Message-Id: <20230806074853.317203-5-xueshi.hu@smartx.com> X-Mailer: git-send-email 2.40.1 In-Reply-To: <20230806074853.317203-1-xueshi.hu@smartx.com> References: <20230806074853.317203-1-xueshi.hu@smartx.com> MIME-Version: 1.0 X-Rspamd-Queue-Id: A60FD40003 X-Rspam-User: X-Stat-Signature: 74kuzzhccwhzc95w8hmp4y6pamcpyjq3 X-Rspamd-Server: rspam03 X-HE-Tag: 1691308195-413983 X-HE-Meta: U2FsdGVkX18mjmJ0R91hE0tHvSnwNXG0NEOo99kZ14kMjmg6OCi4Puzfa57QoyK1tXooVRH2VJHXDQMnhpwK3+D9JpJwS3JArDZOe2oJaDtwOns97cKESEC1l3tMUkUxYgVCGroq8DC5GLYMvCrNsWa86NqPlDcjENGs8Ma8KuVFYVmyHci1hFmXD7MCa53fvr77WDJhgCU+h29CnG9TOF5JqRL3StbKW21ucAY9+qw2zp9zz+ZJ657MBJIUZ5IZRPSLb25up+Z+Ep+TIEnERI4q9mH3EU7MCLeVFudeGXDB8pr7Ls7U2+OwbQkjWBivbeKEdJHRK/+hrQxjubT50XS8+uINMziy1fGTSyWSG9vXP7qE+uEKyrxvBv97PlLDajDth0Mmm/Clo/Ixr+fa4evDXW6aoD/Vzj1PizVgO9Zg1EqSwtCC4Je91Ch5zG8VgmEg47f5nYlFgOfWUfSM//Uy+VF+dVzSl+r4BXS8hXY9qjRM9xaLn8DP7AUuthLdIJ6sK3XQZBLaWpplmJigXpICys4bmDoKTOv+j3Z4I4MYuvk9/SNy0T+Y/N0ZC3Rrbz9K/7bq1P8T/JHCgLrq/2HPQdyCEkUnFpIQcUgYOVppesfxTxjRTahbrteRlFVy82o3ljL6LAwWS2pSJkxsZIW1eAkKxIMIk35IzHHLrgD4vBF/TsViZrw8ASN6c/bspfowq3cr5+oazsVZ5061ITSTaxi1/TxszHVorUYHHCY3GMAnXtIsne7uDGHgLsBEg7dSXrxozVBx2EQ0h+ZmzJU6CuMahyM5bh5PnerAPsAO6Gux/bFRpp6uJiiOttmkYnII4TEu7SABc6SzMbsum+PJVvAP+cuzHxjNSs4HiinhhAlz8Uwd3ZyrWMHpntslgKmZl7ZMuj9BRsUliZhpWgXNgzQLIDeLPDl5TBgiXwoOPFR2ztWEJ/c4fEuLSdCm5EZC+HfDLZk9NYhv9sJ GYHS4ALR goVLkAXrnlrPZmG625c9nSj6Ia5dK0krM68KLnODSbKjD9l5/PpeP5jfnbL6KaJ2fAwjgfYcrUKxUp3URVr+Iw2hUiUmaXF/ChZ99SA+hZxAHMgNlu0WvEW70wRqz/jjheFT+O2gMREToEJGO/P5gxtn50Z+keM3j7xcb7O7gkt9hc2wKzJJ6ALJ/1pWe38iweOc2OhnN1WkMhgj2YmiIiUT8V0ihFDMaK1ZVFaH3oERK5rJnv/wWoPR+I0ogUNNGtkQ/rDpfXJnK4y55hvjB67SK26eFWLiryln44MhRo7tKvIhlB0P88e1eEj4L0mY+qgCEIvR1XkVcYH14bwSqF2/UwipT2ONoz6NwV8M3zTXeAhMnVFv7UKN4IE3HM4ZLB7fWt8N+mRov1PdHjOoyRhxYoGOP24lA7bgHfuaSoecpXZc= 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: 1. Provide a definition for persistent huge pages prior to mentioning it. 2. Correct the definition of '/proc/sys/vm/nr_hugepages'. 3. Correct several incorrect usages of the word "persistent". Signed-off-by: Xueshi Hu --- Documentation/admin-guide/mm/hugetlbpage.rst | 31 ++++++++++---------- 1 file changed, 16 insertions(+), 15 deletions(-) diff --git a/Documentation/admin-guide/mm/hugetlbpage.rst b/Documentation/admin-guide/mm/hugetlbpage.rst index e4d4b4a8dc97..1cf3cf58bd99 100644 --- a/Documentation/admin-guide/mm/hugetlbpage.rst +++ b/Documentation/admin-guide/mm/hugetlbpage.rst @@ -25,7 +25,7 @@ automatically when CONFIG_HUGETLBFS is selected) configuration options. The ``/proc/meminfo`` file provides information about the total number of -persistent hugetlb pages in the kernel's huge page pool. It also displays +hugetlb pages in the kernel's huge page pool. It also displays default huge page size and information about the number of free, reserved and surplus huge pages in the pool of huge pages of default size. The huge page size is needed for generating the proper alignment and @@ -54,10 +54,11 @@ HugePages_Rsvd guarantee that an application will be able to allocate a huge page from the pool of huge pages at fault time. HugePages_Surp - is short for "surplus," and is the number of huge pages in - the pool above the value in ``/proc/sys/vm/nr_hugepages``. The - maximum number of surplus huge pages is controlled by - ``/proc/sys/vm/nr_overcommit_hugepages``. + is short for "surplus," and is the number of huge pages which will be + freed back to the kernel's normal page pool upon becoming unused. In + contrast, persistent huge pages will not be freed back even if the task + no longer uses it. The maximum number of surplus huge pages is + controlled by ``/proc/sys/vm/nr_overcommit_hugepages``. Note: When the feature of freeing unused vmemmap pages associated with each hugetlb page is enabled, the number of surplus huge pages may be temporarily larger than the maximum number of surplus huge @@ -76,11 +77,11 @@ Hugetlb ``/proc/filesystems`` should also show a filesystem of type "hugetlbfs" configured in the kernel. -``/proc/sys/vm/nr_hugepages`` indicates the current number of "persistent" huge -pages in the kernel's huge page pool. "Persistent" huge pages will be -returned to the huge page pool when freed by a task. A user with root -privileges can dynamically allocate more or free some persistent huge pages -by increasing or decreasing the value of ``nr_hugepages``. +``/proc/sys/vm/nr_hugepages`` returns the total number of huge pages. When this +file is written, the number of persistent huge pages will be adjusted to the +specified value. A user with root privileges can dynamically allocate more or +free some persistent huge pages by increasing or decreasing the value of +``nr_hugepages``. Note: When the feature of freeing unused vmemmap pages associated with each hugetlb page is enabled, we can fail to free the huge pages triggered by @@ -95,7 +96,7 @@ pool, a user with appropriate privilege can use either the mmap system call or shared memory system calls to use the huge pages. See the discussion of :ref:`Using Huge Pages `, below. -The administrator can allocate persistent huge pages on the kernel boot +The administrator can allocate huge pages on the kernel boot command line by specifying the "hugepages=N" parameter, where 'N' = the number of huge pages requested. This is the most reliable method of allocating huge pages as memory has not yet become fragmented. @@ -173,7 +174,7 @@ default sized persistent huge pages:: echo 20 > /proc/sys/vm/nr_hugepages This command will try to adjust the number of default sized huge pages in the -huge page pool to 20, allocating or freeing huge pages, as required. +persistent huge page pool to 20, allocating or freeing huge pages, as required. On a NUMA platform, the kernel will attempt to distribute the huge page pool over all the set of allowed nodes specified by the NUMA memory policy of the @@ -406,12 +407,12 @@ default huge page size and associated pool will be used. The ``size`` option sets the maximum value of memory (huge pages) allowed for that filesystem (``/mnt/huge``). The ``size`` option can be specified -in bytes, or as a percentage of the specified huge page pool (``nr_hugepages``). -The size is rounded down to HPAGE_SIZE boundary. +in bytes, or as a percentage of the specified persistent huge page pool +(``nr_hugepages``). The size is rounded down to HPAGE_SIZE boundary. The ``min_size`` option sets the minimum value of memory (huge pages) allowed for the filesystem. ``min_size`` can be specified in the same way as ``size``, -either bytes or a percentage of the huge page pool. +either bytes or a percentage of the persistent huge page pool. At mount time, the number of huge pages specified by ``min_size`` are reserved for use by the filesystem. If there are not enough free huge pages available, the mount will fail.