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 33EB1C0219E for ; Tue, 11 Feb 2025 16:50:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BDCD3280002; Tue, 11 Feb 2025 11:50:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B8BCB280001; Tue, 11 Feb 2025 11:50:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A53BD280002; Tue, 11 Feb 2025 11:50:53 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 88AC5280001 for ; Tue, 11 Feb 2025 11:50:53 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 2F358160800 for ; Tue, 11 Feb 2025 16:49:36 +0000 (UTC) X-FDA: 83108249952.18.2B84AA6 Received: from mail-qt1-f180.google.com (mail-qt1-f180.google.com [209.85.160.180]) by imf15.hostedemail.com (Postfix) with ESMTP id 4DBCEA0009 for ; Tue, 11 Feb 2025 16:49:34 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="QC/29pFZ"; spf=pass (imf15.hostedemail.com: domain of fvdl@google.com designates 209.85.160.180 as permitted sender) smtp.mailfrom=fvdl@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739292574; a=rsa-sha256; cv=none; b=PyTQqHky3P7VbYNgIWdpgG9cnng+AmlYq0vZebBml0pWGTEQdyWuGL4iRHLmhYyrEQv7AS lom9dhV6Ie5PJloJYZJ/LoHaQ/z2kjIYv/j5V+zS2+PWyJUM8hrDqafLwVqtOdW4qBzgQ+ OmpVEincM5Izi9zdwateSQM83SX0PS0= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="QC/29pFZ"; spf=pass (imf15.hostedemail.com: domain of fvdl@google.com designates 209.85.160.180 as permitted sender) smtp.mailfrom=fvdl@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739292574; 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-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=R1nIuSZ6KxwFnGB20Da8+JNpyVOtQk4sXCRgyB042lw=; b=LsT5T9ZhB1FFBnrO73xb2ffgh4pw8DaGUp3mIA2tNj+XDSbHtGmSKz6FWexMhOkjhaOUeg +tHdyXmDJz8PhGGueuyH8JCrPM5P+mvW+wIdSAgg8TSRjUu+wQVZRQds7ria4AA/bATbQs JzFWeLV3ew61PptOxPb86ol5bghArEg= Received: by mail-qt1-f180.google.com with SMTP id d75a77b69052e-4718e224eb1so191051cf.1 for ; Tue, 11 Feb 2025 08:49:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1739292573; x=1739897373; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=R1nIuSZ6KxwFnGB20Da8+JNpyVOtQk4sXCRgyB042lw=; b=QC/29pFZuhba0xuRhraOiUub+k7ekpIvIP0pkKyUylYYfQ0rqjzi7U0LQT7VCl2lC3 TiQVykufn3YkZUmI8VJlMzYdLxeAp/WKlLXMsM2L6QxYYW8Ou4fxCkYV3M3t0Ue9sySR i4L3uVwLUdbrRv3CI5/34IXS/W9s+RHd2auZLAqpifzeU9VkG6Wtzg7+htIRhbbk0RVX BN55jObHJY2+3Ks2inctnl0fWkcl6iNAX2ZjgA8mVotoJBOFD002n0wWruuiB1mt+737 tGaa+KjuBfbGRJWdAUfgOAANfKgMe+WiTXEps4k29Xwe94e8eNjLbk6kHRG5ggoHuBty Xr7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739292573; x=1739897373; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=R1nIuSZ6KxwFnGB20Da8+JNpyVOtQk4sXCRgyB042lw=; b=Ae9Fw7nvBjbrggj81F0D4Rnr2wyXCe1iuZMLd9qFMN8KS0AGx6Mi6tY+D7zX43lyf2 3E39Umg5cbwJmgRMkR8eQG3YOOv2qN/LgrXJfBtVAuknT98sa5iIQK8J26JA5ypoocsG VZu6YQhldMRZErT+eS/WhnvytTQhfOqf+v25UM4C1oE0CPsXrseaz8E1RZutTa+5TgB5 pUrVpiEFt7kVU7RyIwMbZXfL3zlTeKbT4VLmn5CtWCUUn1fCYK5la3zM4ARe3K+MaXUc Au9weBfp8WZSfVoQZ9t+lWVqpi8mzM42fA12C05hRsXdFtDGdosuiWXg5BR8cK/dKf/3 kHlg== X-Forwarded-Encrypted: i=1; AJvYcCXRo8DfKya72Hh1ezcAqyEolpnO+nlPqqt6xrSZxkIhECcmfNY168NRLwqutYzi2RAvgMxA5Skcqw==@kvack.org X-Gm-Message-State: AOJu0YyMv1gXDp66H/mkch7ejULbc0bmsvxbHJHd5O7fTTqLk/xsoJvx lNwZ41rhtPdUgr2BQmOgboyxcmzmUIhLqh4t8tNabU+oMF43R/E1UgOUoaWYAigKu8J+B422xhv ehMAzby0iH3Z7IHZwGI97XTGoDhakVxwDFuGT X-Gm-Gg: ASbGncsqKJF6qQrMLoJ9tzbS/VKUR5OfVkBhFaFRUnpbzOla/SkbKJh+BsviLSX/fzt i8u2WwKwdiPjPhuySBDDUo5aJ2ybNbNbQ/zJ/Uib3aZUV8qhM4xFSmaXo1HrfNLKvpH4kzQ== X-Google-Smtp-Source: AGHT+IH8gUG52NWRYpj36k6MCwda2guvEljw3Ky/hTqjGuftzb+0ECL3vc6zmSWo/Thb2/ncHMTAPy56FIwoZlZHe6g= X-Received: by 2002:ac8:5dcb:0:b0:471:a0ae:7e3d with SMTP id d75a77b69052e-471a2611629mr3713081cf.20.1739292573306; Tue, 11 Feb 2025 08:49:33 -0800 (PST) MIME-Version: 1.0 References: <20250211034856.629371-1-luizcap@redhat.com> <146d87a2-ad3b-4070-862f-c92c91df27b2@redhat.com> In-Reply-To: <146d87a2-ad3b-4070-862f-c92c91df27b2@redhat.com> From: Frank van der Linden Date: Tue, 11 Feb 2025 08:49:21 -0800 X-Gm-Features: AWEUYZnqU281kPkCnUAwwbqyE9s1EUDqnjjPuaysAudIXiBNzTskWoeir07plGo Message-ID: Subject: Re: [PATCH] mm: hugetlb: avoid fallback for specific node allocation of 1G pages To: Luiz Capitulino Cc: Oscar Salvador , linux-kernel@vger.kernel.org, yaozhenguo1@gmail.com, muchun.song@linux.dev, linux-mm@kvack.org, akpm@linux-foundation.org, david@redhat.com, rppt@kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4DBCEA0009 X-Stat-Signature: 5w7d4uwgj6yb4oy78mhzj5f3btdhezqx X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1739292574-598395 X-HE-Meta: U2FsdGVkX1/37NsJtcQO+dY6Hwk4OXr2rYbegR1aAo3Mt1d9+eWGmSwqUhrRuWRLQlZnDmzZ6Up7/K714WaEtcnPSm0PkyetL7CqyVnQuyfOxIDUBlEEDMuXtIAf/JfL4Wl90k/G+sHJo6ULV3hdsyWxGswWPLbld0TKKAu4maTRwm/txyU7XaC+AczIeGlp0o1IsIX7H6kMd2Ebad3OcYr6+qT9o4tYdzOjjlnDAdQdgdvzKCXFqUNgCXwC3pvn9PkVmQ0IqHbP1HAPHBYdXTjFScXGvJW6v2d+gcH/sSYAIyD4cfZLN5g11qGY3BKVYtZu2zAEnZRlVx+m2VGiOjTgVbLuh82D0+1Eh5o/KhJ5MH1gHtMvibsiN2dM3muFFotPeUpLtD/5zpQENOsFDqPHinZZTwFLffh+waqzUDt/clLzL22IX0/nxBD76uVb3MEObh+uKjN2AvevG57MqYiXVUlyF1Li7ibpfpMFG8PXFMtDVz2GS//DSNqq3Wdh538KOi7V3xGRyxiK6dPWJdivoRRcgT5cOzgPd0Hrwz6AvDOPHvFYQTjdifymii5vvhXAsj1SIq95ql85173GGoZZrgZjM1qYaEcUV3SmnLyxkA4quxs0tnR614/PsY3sfjiGoUEZcHwLdmtXo4gYHPr2B535q8sE9cBD62Bp5OYJJYlye1DTjOFUdu8zxFcbPtZHVx2Gdry2yTU3KQ41cLX0tRpBcnYY0JOFOsKBMqeXHz1YgoBJ+XXxgoXrvECrJ8fE+ld2MOOCAGHXnCsfLo4t05dW8UmJlp+IWy+zQkUhI+NDVNgj+YhTKQAKo8RRe6y0IRezPk8QOQfuhLrzEYv+Mt1ZciSePDWKyyVZcaq17i0irOuENH7GwC1KBU0P2Rj5dsYtOrRFYb8Me6x+k+IJYbeRM7eybBKaytbIO0Tocem+nCClY9N88zE1z9j8gupG/SuYBCep5GKTBE2 GOFLx6YN H33FKPYHqqPXe4lXQZPTpe0Xa1k7H6eF2Xh37vdvZg7ElbJbdeOqq8f8NgNd5VWlSkJF0M1ixQ8kxj9AIl0oJ+hfS4kUv3rS37+cMxh1q05GkqPnjuViI5nshBLeYWjQB96CCen727LrWhtvqKVSTFJlYxTEo7v4Np1buTSHZyhdjQY5i0bsF06eX/SbAfGrqlPJ+LKHPTeHDaT2N5xVIb+qVjE74Fr2TtvDNDsQGp1+3vYFCczPqRmVHCefaNk1Pcg0kWPtL0pqfxTE= 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: List-Subscribe: List-Unsubscribe: On Tue, Feb 11, 2025 at 6:51=E2=80=AFAM Luiz Capitulino wrote: > > On 2025-02-11 04:06, Oscar Salvador wrote: > > On Mon, Feb 10, 2025 at 10:48:56PM -0500, Luiz Capitulino wrote: > >> When using the HugeTLB kernel command-line to allocate 1G pages from > >> a specific node, such as: > >> > >> default_hugepagesz=3D1G hugepages=3D1:1 > >> > >> If node 1 happens to not have enough memory for the requested number o= f > >> 1G pages, the allocation falls back to other nodes. A quick way to > >> reproduce this is by creating a KVM guest with a memory-less node and > >> trying to allocate 1 1G page from it. Instead of failing, the allocati= on > >> will fallback to other nodes. > >> > >> This defeats the purpose of node specific allocation. Also, specific > >> node allocation for 2M pages don't have this behavior: the allocation > >> will just fail for the pages it can't satisfy. > >> > >> This issue happens because HugeTLB calls memblock_alloc_try_nid_raw() > >> for 1G boot-time allocation as this function falls back to other nodes > >> if the allocation can't be satisfied. Use memblock_alloc_exact_nid_raw= () > >> instead, which ensures that the allocation will only be satisfied from > >> the specified node. > >> > >> Fixes: b5389086ad7b ("hugetlbfs: extend the definition of hugepages pa= rameter to support node allocation") > >> > >> Signed-off-by: Luiz Capitulino > > > > Acked-by: Oscar Salvador > > > > This was discussed yesterday in [1], ccing Frank for awareness. > > > > [1] https://patchwork.kernel.org/project/linux-mm/patch/20250206185109.= 1210657-6-fvdl@google.com/ > > Interesting, thanks for the reference. > > I stumbled over this issue back in December when debugging a HugeTLB issu= e > at Red Hat (David knows it ;) ) and had this patch pending for more than = a > week now... > Looks good, I'll drop the same change from my upcoming v4 series. This will create a contextual dependency, but that's ok, this one will go in first in any case. Reviewed-by: Frank van der Linden