From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f51.google.com (mail-ot1-f51.google.com [209.85.210.51]) (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 412CB35F16C for ; Tue, 9 Jun 2026 04:23:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780979037; cv=none; b=JUj6lRWCH3JzHss2zg3ItfYn5vDhPYxU/L0YrbevjP2dhB4dJJu7SgHos/q8sn+eeaKy1ZmH70XzvFSRbcoB+wRniejvhxea7ZtXFKxOCR4ZQiAPZi4L/7+2J3MRIqzBTFj9kITfISBrmLIcgVpCAWfvQyHaWCDjLzHPB0PZ78c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780979037; c=relaxed/simple; bh=le8AUkPRAppOfcsVoDYkP1+zdk2nSK/uz+YqxDff8U4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Jq//W/7ppaO8X8KB4Tq01LeYEZNnsYiDZm0IblmplgmSpjEF0zW1RbJ8oT7qYEKA3WNN4OKvxfp3SIIgB/RGA1xr8MS2Y+0WdJIvgGp9+sZ9/tMcyNKhCEYf9tellw7jP655Vzh+mDIOyPQwtlS5+A9NjjvZGqBFRuJI6ib8fg8= 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=Fm14Lp3w; arc=none smtp.client-ip=209.85.210.51 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="Fm14Lp3w" Received: by mail-ot1-f51.google.com with SMTP id 46e09a7af769-7e6da33a561so4196475a34.3 for ; Mon, 08 Jun 2026 21:23:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780979035; x=1781583835; 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=xIp1fAQDnn86oxS0ZtsIzqUmKzi30Ra2bA1c7IATHpA=; b=Fm14Lp3wP2S2GQ/VB9Xe729cwOau5pchmVnEw6E0c5PWuLH+Ve8+fD7FZiDBRtcwhO 6MrEZzkn+vVXUIXuoh7PgXaI7sE4PdTxnXE+lLQsJ6F+iVHgJ0TTR0KA1o2EDFPy3NmY FBsBJPqq9yLS0f5Z1qix8hugWYJRtYlZIdbFsTkZtBMrZBocFFRAuhGMVZglJkIITOPz wWGyrFaP2ARRlklCzU+bgKuvawvVdyAMy44BJ0Y7W6VN5Tqfvlcasj/FTbPgMzUA9w/U HdWfN7O0i14xOIsIuAlA8VyQpknMfFdZHKaKRQdqmelA2KJEUdAsrCfMvE7m5PR2dp82 iP7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780979035; x=1781583835; 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=xIp1fAQDnn86oxS0ZtsIzqUmKzi30Ra2bA1c7IATHpA=; b=L4y768JjW2zI50x4m1kBfBj5lS2tHeYzN5l6w7azg2ckW1eAbVH2OCmH4XkoSAUCmV lFVyOVf2AvytSVbqF1Qj7xFa+8WJUj/HuIZ+g5vpHHCY3zMhb/qC0Bnx2r4e/13jhOuS dWZetb2uav7NCDSw1aFCvpbZemlCKOfcn6fQvrBwArdggnl8LYhPssUYLggYnaF9U8Wp qOWrtgENhzhTbT6m4RssrdwPD+hNo8dYstooV7uzzfv+YHrImKjH+5lJ2oTqBrbhtgcD DGIAGTmlqagf9JsrSDJY9/+FcoYB5dfOCQ1FkOfaKqxpnnQyRcybEN5n9kX9i1S33CaL N0Qg== X-Forwarded-Encrypted: i=1; AFNElJ9zkOIETNsKCU0ptIgbwpW6sK329adEFp5rjU4XFsQcKxDCn47wDtwYOKkqSRYg7bkrbmLv5B+jlElxMCI=@vger.kernel.org X-Gm-Message-State: AOJu0YwQzGSkWwwna0RGzXOO8tP7PnKF5fHkX/9mnDNHsLXZZrcRUO4a Ovbetj/HkkcwMrpGDwh/xkA7ry/IkMxbKngu0XnPDd52roJ8cWIqzV4N4yk1CQ== X-Gm-Gg: Acq92OHrOKHVca+xj5O+exBCnx73AQIHf29ryFMNbq3Jyy3hfMgASDyIA0K+ebWPeyC Eo7c6D/alSx+GToA3bh4xCZohbK3MeutHOR6wuPXGehgfvPDpBSt2JNag15e9ACub/T7bwMjmo3 9fs+u+Ujd60fiOSikZzLJNSZx3w9Ae8Y69IMx9lUypGwJCcu034ED6YmqfJocheo9TzFIRlzzgy LHx6I4kue2yPo/ETT/ou9NbiOcjtz+nt/3bBCyK4Y2+KFRAm8bt3AyrzJ4ZebvK0Y1S11mJLh87 B1hLBG1pgL+kMRx2Xnb0gl2DNIA7GzK1nbkh+8RZQOwcvgNliBHBaZS/JaAD3/OHp4aj9Ck55fT S1KZg0x6Gx2fLlPXC2iBb7jngB328AWbDFyKRX239BC7VniQjzR0nsD6HnWRrYWiyuT2XGIrgnJ T5WIcDaaTcdyqTVBCaM0bbdraPieWSo1KCdjUrTDWIuLn8cCvupM37VySRuRVexWIWKyVYTesha 4U= X-Received: by 2002:a05:6830:3883:b0:7e6:e385:4c1e with SMTP id 46e09a7af769-7e70c60dec8mr11089234a34.4.1780979035155; Mon, 08 Jun 2026 21:23:55 -0700 (PDT) Received: from localhost ([2a03:2880:10ff:54::]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7e6e745fea5sm12954375a34.5.2026.06.08.21.23.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2026 21:23:53 -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: Mon, 8 Jun 2026 21:23:49 -0700 Message-ID: <20260609042351.143573-1-joshua.hahnjy@gmail.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Mon, 8 Jun 2026 10:21:22 -0600 Charles Haithcock wrote: > On Tue, Jun 2, 2026, 9:20 AM Joshua Hahn wrote: > > > Hello Charles, thank you for the patch! > > You are so welcome, and thank you! I'm newer to contributing to upstream so > I welcome any and all feedback! Hello Charles, welcome!! : -) > > 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: > > [...] > > 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. > > Agreed; actually, after submitting the initial version, I went back and > have been working on adding per-node reserve hugepage counts to the hstates > and adding some selftests for them. It's going well so far, but I'm > hitting an issue in accounting where, after reserving a static hugetlb page > on node0, reserving and then freeing a surplus hugetlb page on node1, and > then freeing the static hugetlb page on node0, followup reservations on > node0 additionally count towards surplus pages even when there are free > static hugetlb pages on that node. Trace-cmd revealed allowed_mems_nr_free > is returning more than what was requested resulting in the over-allocated > surplus pages to stick around rather than be freed back. I see. So from the perspective of the system, even though you free the static hugetlb page, the system views that as unavailable to other reservations and so future allocations go towards surplus pages? How exactly are you freeing the page in this case? And how long do you wait between freeing the static page and allocating the next page? I wonder if you are seeing this issue without your per-node hugetlb page situation as well. I have seen quite a few hugetlb folio reservation restoration accounting bugs recently, including some that I think are still in mm-new. If you're developing against anything other than mm-new, I'd suggest trying to build on top of that to see if your bug still persists. > I plan to dig into > what's causing that, however, if doing so leads down a nasty path of adding > per-node accounting, I may need to fall back to the first version of this > patch (but with selftests) and be ok with simply doing "a bit better" like > you mention. Sounds good! I wonder if it would be a good exercise to measure how much we typically over-allocate by when using the simplified calculation I noted in my previously reply. > > 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. > > Agreed on this point as well; afaik, surplus hugetlb pages are viewed quite > differently from static hugetlb pages where surplus hugetlb pages are "best > effort." Obviously we should try to reserve the requested amount, true > users of large quantities of hugetlb pages should tend towards setting them > on boot rather than dynamically. Yup, totally agree here. > > [...] I wonder if an approach like this > > could work: > > [...] > > 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. > > This is considerably simpler than a per-node reserved hugetlb page count! > If I end up falling back to my initial patch, I will absolutely be adding > this and attributing you. Thank you! Sounds good with me : -) Good luck and have a great day! Joshua