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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id CDA67C71153 for ; Tue, 29 Aug 2023 03:44:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1F99928002D; Mon, 28 Aug 2023 23:44:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1A99D8E001E; Mon, 28 Aug 2023 23:44:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0722428002D; Mon, 28 Aug 2023 23:44:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id E7BFB8E001E for ; Mon, 28 Aug 2023 23:44:02 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id ADA2EC0603 for ; Tue, 29 Aug 2023 03:44:02 +0000 (UTC) X-FDA: 81175748724.20.6C7555E Received: from mail-pf1-f194.google.com (mail-pf1-f194.google.com [209.85.210.194]) by imf04.hostedemail.com (Postfix) with ESMTP id 8C6A340003 for ; Tue, 29 Aug 2023 03:43:59 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=smartx-com.20221208.gappssmtp.com header.s=20221208 header.b=xrYVvmps; spf=none (imf04.hostedemail.com: domain of xueshi.hu@smartx.com has no SPF policy when checking 209.85.210.194) 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=1693280641; 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:references:dkim-signature; bh=cBg5ksTAsCd+g0ET5QVSOkD7LptBQg14yrQGHEpUrAU=; b=Oe7N6WxYRokmBo3tddpi26w8Ar8JIXFxzzcbd4okglvf7ZKZUi8TU3013hqN2kHDtnIE83 cgtXBhwYfwGNvCU+39sF2QPl83eA62Rbs/DDZkIR/h9uPP1KUqsbKt3cprqrQi3k+EbOdy OOgr4ZUNsJYp1y1Mcl0CeLNSi5W3Ee4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693280641; a=rsa-sha256; cv=none; b=Es65YkUjZFNWADoQdb2cs52yENe2Y3voJhsCikbV907dvoy0wzTr2N5EcONcc4odwZubUK ejNfHe99xJ71PDHEz4ScYphCLMSY3o2WU79HBkkJUE1MSk11ixu3DHJuRNaphrhuZ2y6NB h+Tcgb8tFp6jfi+G4m032rUV0xQuQHM= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=smartx-com.20221208.gappssmtp.com header.s=20221208 header.b=xrYVvmps; spf=none (imf04.hostedemail.com: domain of xueshi.hu@smartx.com has no SPF policy when checking 209.85.210.194) smtp.mailfrom=xueshi.hu@smartx.com; dmarc=none Received: by mail-pf1-f194.google.com with SMTP id d2e1a72fcca58-68bee12e842so2666267b3a.3 for ; Mon, 28 Aug 2023 20:43:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smartx-com.20221208.gappssmtp.com; s=20221208; t=1693280638; x=1693885438; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=cBg5ksTAsCd+g0ET5QVSOkD7LptBQg14yrQGHEpUrAU=; b=xrYVvmpsQyuIwCnDdVXu+PvqwVRHdnGg4o6UuJkCxMwehBhNjPEfO4GkNE5LWo/5lW fbJDCU9ARMXE4M2zbDDHK9eJeKSERiwHHy2xhgk7gr+sbN/CJ1Azh2xppCav4KfGlqCQ nJn5olKAVWHQHN9W8M5NwkNVcJ2jbrH38Wfrxl6Arv/BWfdfSk28sRH0DC5ixgCVglPO 4XVKihiY+l6GhSwWktds7xHvmNAimsPpANGpwboKtzl9rrkWmjDHkA3YGTVOTVVF4xSJ vZ4FCVCW5DHOWIizGpWBZL8U0e6cv0czGKO2dA5xiyKExGwYnQ14FbGbWPWG9kCiJU4o 0+fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693280638; x=1693885438; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=cBg5ksTAsCd+g0ET5QVSOkD7LptBQg14yrQGHEpUrAU=; b=R0LUK2LJ/yXSUqyw6NVRE8JQcLdUuAp7IExOf57PGUoQeV+BLfHQwhdW4FlmJ7R/mp EhhknYtiarFfJYqoxXurSD5IqlrP/SywE7wzAqbQBkc6WK/AD4Bb6vAXzFmb3xu352QB FTyh5rmVlmH1x7FfoRmv1IGeZiLJw/m/XjD2CmfqPSvqyYdyECu9gRfXHbrgryhOSVaN yjm5pRkZMF+W6vEDf9peYH5FryUXEbSU3yqURjLUSHdVRJ0Rc3n4Hd3JIfUj+tNguyKG E/pQ06O4FD+70EVL1Wpmf5v3lHtvTRXyabUnWJ8yhRjNTfuz+EkUj7DbcZKnw+SKsEuU UMsg== X-Gm-Message-State: AOJu0YyKE87zfP5jV3hB018z5wPONrLKglAyJHRQUafO9TjuZo2w7FRT llm4EhP5OIu6ceR1GDo4gW9NAg== X-Google-Smtp-Source: AGHT+IEhhDIIc+y53CLBg1kbx0PF9tqFR1kHAGGmtoHDssJGtwyVRTqB9oF5Ygp+BTtorMqROA6kDA== X-Received: by 2002:a05:6a00:2d8c:b0:68b:da4b:4626 with SMTP id fb12-20020a056a002d8c00b0068bda4b4626mr16690415pfb.32.1693280637795; Mon, 28 Aug 2023 20:43:57 -0700 (PDT) Received: from nixos.tailf4e9e.ts.net ([1.202.18.10]) by smtp.googlemail.com with ESMTPSA id x52-20020a056a000bf400b006875be41637sm7691801pfu.145.2023.08.28.20.43.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Aug 2023 20:43:57 -0700 (PDT) From: Xueshi Hu To: Mike Kravetz , Muchun Song , Andrew Morton , Andi Kleen , Lee Schermerhorn , Mel Gorman Cc: Xueshi Hu , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH v2] mm/hugeltb: fix nodes huge page allocation when there are surplus pages Date: Tue, 29 Aug 2023 11:33:43 +0800 Message-Id: <20230829033343.467779-1-xueshi.hu@smartx.com> X-Mailer: git-send-email 2.40.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Stat-Signature: kq8x33qhc7b98afagkmyzzwetr8m7pms X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 8C6A340003 X-Rspam-User: X-HE-Tag: 1693280639-337033 X-HE-Meta: U2FsdGVkX1+FP37b99TudwL8PUgBQBUC3AVFLBC8Pcwccfbsu6UOK2eoIayY7xMEXYCPMctkA1z8OOT4AYbI8tdTa+mnCtORvMsUWqjVXS0Rh/cabJ0H6/zYSi5AJnaH83+PxKOzaUxRyeqMGPEF+Dgxu09S4Vc9udVKUvhJi6OEGpFOW+NdN4OHhysCpzKkoKXQDmp7FGYlW/M1PGGWR0WPMbEOindgdGEoRkw5SuacpFT7iL+7bopR24+KNxYsGTLfYBejE3goYhr5U35relBuUzTHpl2zzXDqV+Fm1T9G7pUOpU9M9FEyx495QMVHfDimUVRYG2x/h4CGZHDzOcux8SmEECVfqOKgjqV4+FLv4V5hb7YIDx1Sk6egRXUmTKiTO9XzornvttNjlEySj/XiiG/ep5vWnxjYl4jkmT14m6SZPogylYf/jM1YNvdiobbYSUpXWPw+Y/tSAJkMzuKAGI7uZfTZ5lseaA8uoftUHuY1FGK4FU2+lvFpYPy+nCf2Ar37BLu8XUnKy3/nV+80b2IE4rqBKUyvZFCu4bZoCjljY/fsEXnlfTzH5zLcSaPQr/hUgA/gy6rPrYP5LiYB0GgzJSLFHBHMTE8pYRhHNeNiDJlfYsUO2c4+PjQl8PZCGMEISRZJ4i+oCa1A0kGEa4buuw6M0e0U3YbP7Dm8e5L3G6p98rOkM9bYf7PuablILDuPFk4s9hNUWSqTN3WcqcLyLc+px0H9SKCPt7CWJFS6EMV0ffl8pJJmrbFqXJGuwHCb/nb4GSfBNJhQWYdQdL2g1FmgxKL4y1P+UE9YSz/XYkxbDPe4uCeMXwE1ZrvriFiVG0ANbBYzwLcodLULLqqSGSY5iykI2YJJAEG/7jZ1zWmR9K1zTUz+3I4yy6FkUnRY84K9yXal6tmnhCmn62R4Mle+RiCA+CK7J6KAaNmU/sC8+FKqNq66FVBD7IE/Uo0Pvr8hRIeDIDU 0UrMCXMt QNPbWpzd12MTJXnnTsWW+32wCzoQRzBuCjSBD4jReoOomcdeLiR0NOkIys2FcBIt8a142IzvlXQqLIlTSrg1EOVXP654beO+qI6bGO78NNikfzyJ3uYuMwPm8PEjsm90f1VJpKdAZQIWGinwo4H7fMIdpS+v0cJ6KAJsqUbkhvv4/kuEIh1SjttSompzkyjgFVIS8HYI7IiGqOAXYBhn1VpXRfqCx4s4iUYWsFXopunjxc3cj7vvryDzkoj8O3rnmhp+AVt/8BahhTQMI717nJgP2u3rWafUe2mAk5alCYdZuNiuCVHRqsNMUkxkThD5mwJBwRd+VVJ6geHQqsP0RvXignh6JVigYfbpFnHIguvqvJfnkiskCKW7eC6NkPuPFRIVOOg98+tnsiria+odZvo5kZP2FFEv84wvps//66nEEdFUcftQXoNjNW6bXe3RiFcPdVkZgYbP1V2gL8MgEJNIVg2enbzMcM2zP+L1tkUH53gr74hcy7k5HPIR/8+enL5ZR/3y0xc4nfmCgTokoyGg3vom0wI61ql2U6ng/ImfgbAErHXpfwSaqjQ== 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: 9a30523066cd ("hugetlb: add per node hstate attributes") Reviewed-by: Mike Kravetz Signed-off-by: Xueshi Hu --- Change in v2: - Correct the fix tag - v1: https://lore.kernel.org/linux-mm/20230828233448.GF3290@monkey/T/#t mm/hugetlb.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 6da626bfb52e..54e2e2e12aa9 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -3494,7 +3494,9 @@ static int set_max_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 -- 2.40.1