From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oo1-f50.google.com (mail-oo1-f50.google.com [209.85.161.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 89492360EC6 for ; Tue, 2 Jun 2026 15:20:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.161.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780413627; cv=none; b=foThLpWU8L8jStDHsT7y4/kI6ilqTHNaqafKtRod/bwmUa4LwE/a8VN+Gp8dMpkQwwbpC6fa1CZD8ix5dHFJuyc8cbusSoaUnxOUSMa6NbEIX1hINUK8RarA0QSDQ5+6RGTq6AkA72GBmiggAzau+B57N08kFjfKKOxgZwmBVBY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780413627; c=relaxed/simple; bh=sxRpb7gro7tRVeQX3zeIPNRak8aI1QVNpy0t+x6cSYM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jRUaRJy+X4r2rpsBfny7dit6ayj1OvboWANkGK/104fQ0rfnVcFB5viwo1krD+XpV8grVvf/gIwxAHVShSt1bwsB13pQApn5wnfxEGDO3Mn7U8Iu/AS71AiUtEsJRsHZINz4dp84AGKzV+8BBsoEfEtcm2RkXXm0wsTnNI2bFK0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=gRjaEhIb; arc=none smtp.client-ip=209.85.161.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="gRjaEhIb" Received: by mail-oo1-f50.google.com with SMTP id 006d021491bc7-69e06aaf0b2so2882114eaf.1 for ; Tue, 02 Jun 2026 08:20:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780413625; x=1781018425; darn=vger.kernel.org; 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=ioWIH2vIGho0+8O2jaAg9vyx3qwy9l2LVl4YVTBtgfM=; b=gRjaEhIbDyYYjQNj8c5UwXtNYMPBEAcN+6+8pWRmuNa0ijLZ+LSswprEwhAddSrGi2 DgLR02G6elym+mxN8wxWSECGYjkKwJZnXKNA1o7kvbhpx4EMzHoX+lJreW/aQI0o5LPb yHEkaadOHxeu3syDKrpO7howpHNlaeuiACnVuPMtppjwi2oN4xu+r4tlDN32Okqdmtu6 9/cGkKusOlv1XbDm/jdOJPKqdh95wbt+enTpsnLj36QqUdpc8FzLnz8n89FcdIbLYntX L7EJfIoGvSUqSmzLQ2S03Je6oWYXsZKZCtpQ6LiqCh1Q9OTpnegI0huCWSCZKen3pu7d MSCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780413625; x=1781018425; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=ioWIH2vIGho0+8O2jaAg9vyx3qwy9l2LVl4YVTBtgfM=; b=DRrwBcENU3GSyuxkDwOsq7FlZgTPD5k4fiv6tGu6hzt928Ntlnnv3+7xq+TiWAfaXl 2nfMZ0EnP/vqnTD/csKXbuTNB19bUVLOM3MkamLnJR0GiumU9k9LV1oGiM1uIVSEzqFS SHawSFMSC9/4UJ1JyUhnHwv1864Ui0VoLsAfbEB2BP77PodeOEDTWjAuskatERaE1QhS RFdjsxciBa0lw4J4TQxs/jtVgAFNI4WIXjsq1owe/eB2ZOR/ZfiEVVUHzmPLbNt78raO XWcIthA7F2iHQM7bqqtgmOOKJVFod5kV0+GKZBO/GYLr1UiVHgjSUAUHHm8uIYPGaZqd dhWQ== X-Forwarded-Encrypted: i=1; AFNElJ+754HXj9D1Sp9rWhK8V7BjvZCkqu1ymTkosrtBPOph6YEPLEmWqGCe03oKWBxCXZrelECKdCkKpH46Q0Q=@vger.kernel.org X-Gm-Message-State: AOJu0Yzq/E62pJcSEONuqAVoOkxlLnJLVEfJA9f9rpMHlVViv8ZLptXf szRenLef/Id46d4CM38/HUi8p4MSBey+OQV5SnqWJ4ORwvHUJZjU7iGJ X-Gm-Gg: Acq92OFAmF4pSbyKzlAbi8m8pIvF5z0KRFK1Pw/3PB2MtzQNaBJqdI6cLAaq+RYiM0d h+PX1oe8LI1mS6i0gIranzJFoQnMdaScbC7gtauKZnccPmHanYjp0hQHkMtBs3lHw9JYv6I6y37 d2TvFuNGuHBRNuA8FnBc9Xh8LiLWsbe8E1SW+KHabqOVR9WaDF2Ns757FgJrZnmmstKu6vEUINS /cL5rTLf6/3NMkeyTN1hcaYh/7GBN3aXejaqxw2hXj3Lc94Abbzb1sr9E4l4Iqlsv5nDWHRHsrR cmRe8tZb+/LAOTZdBnAHSLSUhiw1joaKJapGlQ+byERSOyY2ddK2Plef3rBRrMsBf/MSCuEiFuF 631T0Go7QKh96cfddzQiiWcDED1lW10EUtRUtZ/X2YVqt1xHXFY5+Zv3kXB2GaJ4EmAXIliMZl5 kbBq8OcltPdU/lL4cch+wKiWVizr9hwyMgxbA31FivGdxOjGCu/n2XYd7KEVShxWdD X-Received: by 2002:a05:6820:1886:b0:69d:8d74:d7ed with SMTP id 006d021491bc7-69e46ac571bmr19177eaf.26.1780413625357; Tue, 02 Jun 2026 08:20:25 -0700 (PDT) Received: from localhost ([2a03:2880:10ff:73::]) by smtp.gmail.com with ESMTPSA id 006d021491bc7-69e46267666sm95902eaf.7.2026.06.02.08.20.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jun 2026 08:20:24 -0700 (PDT) From: Joshua Hahn To: Charles Haithcock Cc: muchun.song@linux.dev, osalvador@suse.de, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] Respect mempolicy when calculating surplus huge pages. Date: Tue, 2 Jun 2026 08:20:21 -0700 Message-ID: <20260602152022.2673803-1-joshua.hahnjy@gmail.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260527224848.1753560-1-chaithco@redhat.com> References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Wed, 27 May 2026 16:48:46 -0600 Charles Haithcock wrote: > Presently, when calculating how many huge pages are needed when > reserving surplus huge pages, the global count of free huge pages > are used. When reserving with a mempolicy, the global count of free huge > pages is used even if some/all of those free huge pages are on numa > nodes outside of the mempolicy. Fix it so free huge pages only on nodes > within the mempolicy are considered. Hello Charles, thank you for the patch! I just wanted to add that it seems like this is a known issue. From the comment in hugetlb_acct_memory (the only caller of gather_surplus_pages) we have the following comment block: /* * When cpuset is configured, it breaks the strict hugetlb page * reservation as the accounting is done on a global variable. Such * reservation is completely rubbish in the presence of cpuset because * the reservation is not checked against page availability for the * current cpuset. Application can still potentially OOM'ed by kernel * with lack of free htlb page in cpuset that the task is in. * Attempt to enforce strict accounting with cpuset is almost * impossible (or too ugly) because cpuset is too fluid that * task or memory node can be dynamically moved between cpusets. * * The change of semantics for shared hugetlb mapping with cpuset is * undesirable. However, in order to preserve some of the semantics, * we fall back to check against current free page availability as * a best attempt and hopefully to minimize the impact of changing * semantics that cpuset has. * * Apart from cpuset, we also have memory policy mechanism that * also determines from which node the kernel will allocate memory * in a NUMA system. So similar to cpuset, we also should consider * the memory policy of the current task. Similar to the description * above. So it would appear that getting an exact number of pages to allocate, and ensure that there are no changes with the reservation or which nodes those reservations actually go to is a lot more difficult. But I think we can do a bit better. FWIW, I think over-allocating is actually not fatal (although overallocating by a lot is obviously not desirable) since we free all the unused hugetlb pages at the end of gather_surplus_pages. I wonder if an approach like this could work: @@ -2260,7 +2277,8 @@ static int gather_surplus_pages(struct hstate *h, long delta) alloc_nodemask = cpuset_current_mems_allowed; lockdep_assert_held(&hugetlb_lock); - needed = (h->resv_huge_pages + delta) - h->free_huge_pages; + needed = max(delta - allowed_mems_nr(h), + (h->resv_huge_pages + delta) - h->free_huge_pages); if (needed <= 0) { h->resv_huge_pages += delta; return 0; @@ -2294,8 +2312,8 @@ static int gather_surplus_pages(struct hstate *h, long delta) * because either resv_huge_pages or free_huge_pages may have changed. */ spin_lock_irq(&hugetlb_lock); - needed = (h->resv_huge_pages + delta) - - (h->free_huge_pages + allocated); + needed = max((h->resv_huge_pages + delta) - h->free_huge_pages, + delta - allowed_mems_nr(h)) - allocated; if (needed > 0) { if (alloc_ok) goto retry; So we compare the mempolicy-perspective "needed" and compare it to the global "needed" and take whatever. Since we are taking a max it should only ever make it more likely to actually succeed with the mempolicy-bound hugetlb page usage, even though we still can't make guarantees since a free page on our node may be taken by a different reservation later. Let me know what you think. Thanks again! Joshua