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 A6893C369BA for ; Wed, 16 Apr 2025 16:33:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1115A6B02AB; Wed, 16 Apr 2025 12:33:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0C0566B02AC; Wed, 16 Apr 2025 12:33:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E7BF6280001; Wed, 16 Apr 2025 12:33:02 -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 C7DC26B02A9 for ; Wed, 16 Apr 2025 12:33:02 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 7F2D41A0479 for ; Wed, 16 Apr 2025 16:33:04 +0000 (UTC) X-FDA: 83340451488.02.CE7F7D1 Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) by imf13.hostedemail.com (Postfix) with ESMTP id 905072000E for ; Wed, 16 Apr 2025 16:33:02 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=p+q7kgi9; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf13.hostedemail.com: domain of fvdl@google.com designates 209.85.160.176 as permitted sender) smtp.mailfrom=fvdl@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744821182; 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=z4sYUnk3RVn3eT8s9+D0SbpGl6UdSZQtvkzjKzBRH80=; b=WOfG/zfp4zcIbyu4P3cwimln4Ake1zLlDPztAGsIv4BZDe7R9L63jGI/wsM1c2QGTjkJcq ZgMrp/wx74OTCeMYDIGmOataGM6tURRQ4MHhvEScNVeqeYBb3dgMu2wuwzCtCgnLK2i1Z2 TlztoHCJWBXBNfXXBqTv9ta+i4drsHg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744821182; a=rsa-sha256; cv=none; b=v1jxvrFPYW+tBPfVqsjVv8qykI+GKVornHWK4kdIsBDPOaDQ0tpKen4xHJL/qbnDB3RkM3 G/oFO0sy5eyQFjRKuK6Sy2JvQpXrNEjnCjjemopu2us+FVSZma/Uk+E8UBjIk73Ygt8bAK Ph/aEqy9/g8JGWc8/s0p2mVeJJW0bFU= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=p+q7kgi9; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf13.hostedemail.com: domain of fvdl@google.com designates 209.85.160.176 as permitted sender) smtp.mailfrom=fvdl@google.com Received: by mail-qt1-f176.google.com with SMTP id d75a77b69052e-47666573242so1761cf.0 for ; Wed, 16 Apr 2025 09:33:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1744821182; x=1745425982; 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=z4sYUnk3RVn3eT8s9+D0SbpGl6UdSZQtvkzjKzBRH80=; b=p+q7kgi9qS2Yhh+sa8nLK4KVZnKAafmaTVZajIRyR+0kDnWiZnFYreWIlfz9mqtjrk Y6KTVw2QmhKucfXeYeZdtNnMUX4aMnbmfNDVpGUn9AXNHPl/UkqtHbD1rzPhDoEXj5KJ DaQjT1svJ8mrNnpH7ixRNXzNcwfzmXqBKggD0M4Ral5BGfzwYb8vj61g2jVeDrLQQDVX IMdumHmM4OZGLvsoDDbAiplrDZAVJqh2ql8U4j9bpgTOYVP6e25GYSQkr+wsibN3rQOU e/00PwNIMU+mk0OKpQVWMGKIOK/dDTvH+eoSCV6P/20bHAlAgDXfqt9CtVtCgs8oGODN 3dtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744821182; x=1745425982; 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=z4sYUnk3RVn3eT8s9+D0SbpGl6UdSZQtvkzjKzBRH80=; b=F6yneW3bSaljLovMVkvOOnTIW0Naf6qPNlRUnXt3DnZy98zwxmUZqnkI6WOKxTgafk RRGO6tHzzWpGfUKlmXU5q34FCmaqCJw6tNXZhwQbDiu40kkWNU2BoOUYZYYuiVkJj++p OBJodz8GGdhF7OIGiFayfV3tvwgNw5i5Pw+uSO/RKRzZ2fQFJHNrV5a4LzZxaLBGvitK Yr+qw4vUUwu5yt1uHNVPbo9OWTM7c8mxDVmtyRg4toofeWQmoL1YxrsM3lmvjsv9vuwO RT335NrXd4wz5bXJVg1Sw4NJZUYNrsilR+1GhIQ0aD5WSO60fGBQs7aUwl8vRPMAqBKv tJcA== X-Forwarded-Encrypted: i=1; AJvYcCUQBhwMYYHOUgqIyu66gMmirjz+6J3MRSbGT2A7PTe03ZSRLKgZ0Eej7XLlNU88RrY0XP1bS2nBLw==@kvack.org X-Gm-Message-State: AOJu0Yxp00U9ZvwH9U9sRf7+H+9SjCzSwkTKZpw7kGEeGKv9zN8TzEH0 oa8s4DM/Cmw+QwKp50vBXu7dwUIeqzGLXGMCQGSt63WRK53qTLW6pugrTJiCXT6/LZeMwaoQTHr vgx8dkcAhodta0Lmfwof9CUJWL5L9jn/pyD5I X-Gm-Gg: ASbGncsKRg4svdFWkjtiGoHsrrGzPa6hVGOnczXMoW1CCGrnf26GmrDwfmokxu/NCtw l8CjeR314PpFfLSq06YjZFwXxaTvET7Rsi4HUB/xs0uKGsmZq7c3yHpyxM7clSikNGtJrXGom/w lQoaQSo4nOeTeIi29h/JE= X-Google-Smtp-Source: AGHT+IFGLnrLi/pwVwS4hx+CL/KHOR7ZtP9NwSL0/fGZLW+5ujtOUmbOivnbfb8MDwVDtXWQCQTdIlvr99JtHYGtvDg= X-Received: by 2002:ac8:5d41:0:b0:46c:7cf2:d7b2 with SMTP id d75a77b69052e-47ad7b5f143mr3120371cf.18.1744821181350; Wed, 16 Apr 2025 09:33:01 -0700 (PDT) MIME-Version: 1.0 References: <20250402205613.3086864-1-fvdl@google.com> In-Reply-To: From: Frank van der Linden Date: Wed, 16 Apr 2025 09:32:50 -0700 X-Gm-Features: ATxdqUGiWah_jJFCkaeSjW57PdesJqsrGy_N98VG-_dxVs0MnOaWnZcw0S6lIuA Message-ID: Subject: Re: [PATCH] mm/hugetlb: use separate nodemask for bootmem allocations To: Luiz Capitulino Cc: akpm@linux-foundation.org, muchun.song@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, david@redhat.com, osalvador@suse.de Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 905072000E X-Rspam-User: X-Stat-Signature: dux95t97jux8kaqa5hp4njifgsnpomw3 X-HE-Tag: 1744821182-603471 X-HE-Meta: U2FsdGVkX1/QMlCyqNsAlXd3FvCZ1GrGxBeJczo2XagRXLHMJ2C8bR7hxv25t5b9bx3Enb9c/OXdDlAhFm3dqHz3fsZRRIRaKiUIWzd1Jc/KOi2ZYXu7/lW+kCdGXMds3dYnqjJeNqpPrCUtDOjT+XKBfHVmorvG5MtKSs5TuAYO6nUZwPyHNPsMYhrpY8kmPmpRGK1XcOpkZBdEgVdpZ8fUOmJVAF/80jxsDM9lVliReCEcpfkNC2ukQjlTdyw1VogecDKxSFI8CuMvWpp7bhtvBJZg1r/Hmz0OvGdiNYOWPU27OBVfXcvYH9fjhZsfdhnbkMv3RDyJUgjW2XRAzL1HseCs27hYIPBGhsaQY/ZNKmaLNpEhRgsMBQeOH2sl1S+efai80TVFdZ8mW2yqRXScfO5Nca1j961wpCRSv2hQgHjvRLbDC+fcWbrIl7xKD4P7JnHBbW5KPfn8W7F8U9YOHD6ZQRkAa/Mb39QiOirba3esX0xoe0orze5hKp12NlrGNNlpdezo7XaFDNgcnom6L0Zj8ZE+ilF1nuwJcUdcWsEc1vKMsj7ohkQOGo2VDUSteBgHhR3g5W/vQb3hf0JIVoNOa+OT9EurHOT2IzQSt2Kyn7xkMvtttM7x1HZUkYz0wvRy7Bt8sLy9mt6WQNTwMeWbGn4uTTY4i2BuNWeorIPzVwBKkGsnVEQ0nSg3thmg0NWzUd4ReUszZ7SSVA/8TIPvfpFaI3SRHmfmiD4vxbkAYgU7vHXuIl74shbcquhNHZr3lxPHqrDIbcbH4vQLNtN8PgWmwciQuLvSYZCCkRz8zOizdN7GvvTxO1AY83h4fY67EZi/GfRmHmncpp1kxycp/6ZQ5LzMMVmB7fXbno4XgOzc7yrRHY+15SpeeUN6HzqwJ9iyyUQkgHsP9fsbrbCGsKPWjN20RNvLPlfOiHZomUSN27t9agss4Rb5E5n/ls5tmNp5J559+FW fHY8B2lv 6M1MlBHkOV28bqIiW+QBvnwZrPo5sm4UeHdzNuOj+9rTmnUmccrsA2wssUTpDuDme0bOd4nHnc4NMgJvLKgkMXOxAVnZXXAF4A0SchxDrFc2VPuWVHXUAUkJ+9saSpq41sPOHP0fmTNDA0giGomI1zpSZ1MbaPTV03f9MM713E0DDpE6o8QE9xM6CnOXumguDE7XVxrMS0ua2vUIPF1uJT7VhRg== 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, Apr 15, 2025 at 6:08=E2=80=AFPM Luiz Capitulino wrote: > > On 2025-04-02 16:56, Frank van der Linden wrote: > > Hugetlb boot allocation has used online nodes for allocation since > > commit de55996d7188 ("mm/hugetlb: use online nodes for bootmem > > allocation"). This was needed to be able to do the allocations > > earlier in boot, before N_MEMORY was set. > > Honest question: I imagine there's a reason why we can't move > x86's hugetlb_cma_reserve() and hugetlb_bootmem_alloc() calls > in setup_arch() to after x86_init.paging.pagetable_init() (which > seems to be where we call zone_sizes_init())? This way we could > go back to using N_MEMORY and avoid this dance. > > I'm not familiar with vmemmap if that's the reason... > Yeah, vmemmap is the reason. pre-HVO (setting up vmemmap HVO-style) requires the hugetlb bootmem allocations to be done before sparse_init(), so the ordering you propose wouldn't work. I originally looked at explicitly initializing N_MEMORY earlier, figuring that all that was needed was having memblock node information available. But there seems to be a history there - N_MEMORY indicates that buddy allocator memory is available on the node, and several comments referenced the fact that zone init and rounding may end up not setting N_MEMORY on NUMA nodes with a tiny amount of memory. There is also code that sets N_MEMORY temporarily in find_zone_movable_pfns_for_nodes(). Some of the commits went back a long time ago, and I can't quite judge if the comments still apply without looking at the code more. So, I chickened out, and did a hugetlb only change to fix the hugetlb issues. But it does seem like setting N_MEMORY can be cleaned up a bit, it's definitely something to follow up on. - Frank