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 81C95C19F32 for ; Thu, 27 Feb 2025 17:32:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EA66E6B007B; Thu, 27 Feb 2025 12:32:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E55BE6B0082; Thu, 27 Feb 2025 12:32:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D1D93280001; Thu, 27 Feb 2025 12:32:31 -0500 (EST) 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 B15C76B007B for ; Thu, 27 Feb 2025 12:32:31 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 227A6A430D for ; Thu, 27 Feb 2025 17:32:31 +0000 (UTC) X-FDA: 83166418902.19.D16EBF2 Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) by imf22.hostedemail.com (Postfix) with ESMTP id 462F2C001A for ; Thu, 27 Feb 2025 17:32:29 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=IFMkBjrj; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of fvdl@google.com designates 209.85.160.179 as permitted sender) smtp.mailfrom=fvdl@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740677549; a=rsa-sha256; cv=none; b=3ggGxF0HB2fe55TZbFFET7FiKIgiXZYqLlHgylHON4Cti63a3FDa1kNJOW+CEC7I4zXLFr wWayI4kH3rcw14qG+iWp8pWiBY2pxC8QKmlXrBZXlYXMG9ZVTe2FsCfC+Q7a3Y783r8Wwo i8XkLgZtmfbAs2QjDC1NKxroM7YvDyM= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=IFMkBjrj; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of fvdl@google.com designates 209.85.160.179 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=1740677549; 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=AcbhEh9hMZ5qsc9WvHnTGNUOu6iJ76ldwk6sVXnK2BI=; b=YNdNpOblzDF9RQV22dPBuwbJH9sgoOnULTg4v8AKPqAEuSqxkulJj65Fw6weLB6MsAmsdE 11lAa7/Kh73gPfhAeqW0CON6x1qzcKHnX1PmZkNrkJJs77wQRkqcCJJxFsfq5E32s+GdKr mKtvAhqHIobfPZx08eNawdOjyep1kYI= Received: by mail-qt1-f179.google.com with SMTP id d75a77b69052e-471fbfe8b89so1791cf.0 for ; Thu, 27 Feb 2025 09:32:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740677548; x=1741282348; 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=AcbhEh9hMZ5qsc9WvHnTGNUOu6iJ76ldwk6sVXnK2BI=; b=IFMkBjrjPZQisHLjw5PvrdkwvxErJ3fGtmvP8UqWcJMqVhYWGIH+p81I26XUURshQc BVaIVUMwV9frBrDVv+lyx8RJXb5DahPkQjQTJ3RZKNVcUnaOOKbXjTTGwLqb+tKnD5c5 9TCWqQT+KtU4TSCDFsnnX2V3bxKUxDOCHhtnJ2zBV/M4+KZVFdyHRdku7eP/61qMiP1v fSHrzGdS3wsWyRSAHd16jnkszj4jW+X96pf9kp/xIeE1gZpNkV54/Dpa1cD4hVKOeNSK Ue3HCKStCXDpC6sp0NTcQjs/tOwt1XBkiRXSWUeB+n33yFifY2w/opmzm+FWo5wjzu2k lvlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740677548; x=1741282348; 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=AcbhEh9hMZ5qsc9WvHnTGNUOu6iJ76ldwk6sVXnK2BI=; b=VtDFI9Ne5gRzLSaTaFvkMHt7GA/YiYG3fLKNJ6XPiR/ZdOBydFO9VbKlJ+yYBSzkPr 2qPrn0MgzcI5fUOasyIvqRtr8by/bIwheslQMxJHzECz/t8mRkEf2PGuEJnRPrwNXY4B Bim38y6tanD6Pn9uQK6ypQDxdKW+lyqv7TiDgS/ERvHAk1bOmf1IpU1ZGWc8ycPFxprG tE1U0mlhIF7NbzV8lWNQS5pfq/LDgwtpGYmKBcZ9KjnUJ5DWlJukd2B8MszEJjPnMVDL bdBrJJ2o09PDHXKRumvDXp5/nStYL8Fk4lADxGQo3E32+s2bFjR7C61AvNS1/OB7X6kn g+Ww== X-Forwarded-Encrypted: i=1; AJvYcCURC6LiOe7K+QjSDKGJUCcX+8VLcW7tSRUjB02OhnOtEDKHXdiVJByY6D3/vb0Ut0sBajrf4sikbQ==@kvack.org X-Gm-Message-State: AOJu0YzjinMCVI8Vj8RkvzNiawdmWuQFoTKGk5A8P04DudANYrA2FeWd 8Qa5n7GnfjgJH1p7BOdfUJBjZrT98U09IJ3QlIeRS4lcbfI0Qkavn/O4wu2YRwX0uJGKhRegHmP 7ummPIZcuQw5uwv31JA8/rAQfBO7njVoKblHd X-Gm-Gg: ASbGncvzxAcpodRzqRz/lpboap+MUE9bEtMqrlvprmhas8yEOv0NHMLnE5UwB8UMg4m ghvCH8pcu39UvgLG+urzLv4h0HdwVUdzoYDqo7FRseOq89wYqvSFpJpkhihLuDDJg2D5zF6TN8Q 3usqp/ X-Google-Smtp-Source: AGHT+IFrYJNNwmBAFlcMxIdAWm4vNnKbsEcLzhZTuS1BHzxgJc44+uCn1lhgkKXCzZY1msiEDzt62MKxw24kvbP6i9A= X-Received: by 2002:a05:622a:118e:b0:471:f560:27dc with SMTP id d75a77b69052e-474a7c7b02fmr3212451cf.27.1740677548198; Thu, 27 Feb 2025 09:32:28 -0800 (PST) MIME-Version: 1.0 References: <20250218181656.207178-1-fvdl@google.com> <20250218181656.207178-11-fvdl@google.com> <20250226180900.GA1042@cmpxchg.org> <20250227172014.GB115948@cmpxchg.org> In-Reply-To: <20250227172014.GB115948@cmpxchg.org> From: Frank van der Linden Date: Thu, 27 Feb 2025 09:32:16 -0800 X-Gm-Features: AQ5f1Jo8O8j3DkJCzRv8ZoeklVnTVB7mpsmpsFjcsNjR_kmG4CiBpSSVpujo95c Message-ID: Subject: Re: [PATCH v4 10/27] mm/sparse: allow for alternate vmemmap section init at boot To: Johannes Weiner Cc: akpm@linux-foundation.org, muchun.song@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, yuzhao@google.com, usamaarif642@gmail.com, joao.m.martins@oracle.com, roman.gushchin@linux.dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 462F2C001A X-Stat-Signature: mcxphef98iqb9rj6udb5kys1y4sufsg6 X-Rspam-User: X-HE-Tag: 1740677549-308900 X-HE-Meta: U2FsdGVkX18WY5p9IkeuEV+KbIDhH1+W3P+EuqGDOlw3IjO2NCNIy676hVkFQ1U1B70YoqYcpTMw6EjR+Fe668IeME54kNoZ13sWm9qNrT8083tpqJKTzojsHgI1NlwGr7FyEp350/dcspinjatldcL/5lxO8QyvuJ6bJOvJbScIvUZDRql5j2e7NH2tK/H7Q5qRX0sNe+ilE+oiEDmwdPMf+FbtYwrd19/2pJrqh8EhP1Z0H0lSsXCKhI81qQ8adGqzo3lQ3uxbL1O8tHPIPCc1BXjPUh9kqLK4GjkwrkgezDCDwJ04clp40b9VudHF2GnEOfKXOOpfibUEucrSX846yIsTJn6KjUGTQLBf+nIsCj6GVd0P9kSLltZUOeTZ51J18f3cRrJcNHHbBS8JL2l/CIVEgAUlrOW6SrqIFDqqZrssM4Limxjuzr8+UBZSkxDqdyzss+expyCyYgRl9dYKlG+ZXdJ3OOH+RDJTpavIQuOWEDduIU6WYFrouYDbhE3G5+bJ6NlQFTQW+0ojogRh6/aprJjMO5F3eXZqbCfK1GPS3Du8YwdC+yHQPUgfHaLj94Fdh/vRjs9B5wKjyAbVA8NfGQGIitAlzd9JCfpivKrKhiWLn4QJHemN3lPqWjMptdX3emXvx5j7djj3hceGXQBRasWr0DIZHA0P6r/KNLC91ISEHT9gcZOU6juS3PVw881MbVG/jRBqgUbLg8ka99vaGVJJeHvoXti8eThFvWrk6ch1nbNj/3IyUjGeR8brja4D9Ja7eiW/shcmJNy/pUzt1qAzkH1vNkwppWKiAgDsCONAw1Fvo46Z5y2S+ru+9NJX2or4i8Ffn0ccp35qTWETc/xDYiPNTlWri1/QY89bZz4PUrRJk+hNl5tyd2HLg78lWvmv3P1QvsIgn7Fx+yZs3zpxw6ZwVnvXU0GTlEKU7lmAcntoooEpCvFb9Ymf0lgAmMXk5TuxcNd dalHtQyI voTUoQkXTTzcz6eGgik1JPmmjtBLu2PdmwxH71Dxx5KWI2u3ohfO9sCMG5yPeG7S6YiVJQtMf7BV9LrIhkyf81PjpuWONuAkwN6UssUlr0Qwb0C5MJ53Brv042KbCHMOVcc0M94VeNgs17guSbO5nzaznScd6HLFY11yQMciOXT/24KPUnJNRHlO4f09nXodPWQf7VvPIXRe9vtBof8JymxCdBX0zyx/NulEHEP6er/XmHIxknyr2eAADP6vhbrw2pkp5 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 Thu, Feb 27, 2025 at 9:20=E2=80=AFAM Johannes Weiner wrote: > > On Thu, Feb 27, 2025 at 08:47:18AM -0800, Frank van der Linden wrote: > > On Wed, Feb 26, 2025 at 10:09=E2=80=AFAM Johannes Weiner wrote: > > > > > > On Tue, Feb 18, 2025 at 06:16:38PM +0000, Frank van der Linden wrote: > > > > @@ -489,6 +489,14 @@ config SPARSEMEM_VMEMMAP > > > > SPARSEMEM_VMEMMAP uses a virtually mapped memmap to optimis= e > > > > pfn_to_page and page_to_pfn operations. This is the most > > > > efficient option when sufficient kernel resources are avail= able. > > > > + > > > > +config ARCH_WANT_SPARSEMEM_VMEMMAP_PREINIT > > > > + bool > > > > + > > > > +config SPARSEMEM_VMEMMAP_PREINIT > > > > + bool "Early init of sparse memory virtual memmap" > > > > + depends on SPARSEMEM_VMEMMAP && ARCH_WANT_SPARSEMEM_VMEMMAP_P= REINIT > > > > + default y > > > > > > oldconfig just prompted me on this, but it's not clear to me what it > > > does. Not even after skimming the changelog of the patch to be honest= . > > > > > > Can you please add a help text that explains the user-visible effects > > > of the toggle, as well as guidance as to who might care to change it? > > > > Hi Johannes, > > > > Thanks for your comment. How's this: > > Thanks for the quick reply! > > > Enables subsystems to pre-initialize memmap in their own way, > > allowing for memory savings during boot. The HugeTLB code uses > > this to initialize memmap for bootmem allocated gigantic hugepages > > in a way that is done by HUGETLB_PAGE_OPTIMIZE_VMEMMAP. This > > means saving this memory right away, instead of allocating it > > first and then freeing it later. Not allocating these pages > > at all during boot allows for specifying a bigger number of > > hugepages on the kernel commandline on larger systems. > > That makes sense. > > But if it's infra code for a hugetlb feature, it should either be > something that HUGETLB_PAGE_OPTIMIZE_VMEMMAP pulls in automatically, > or at least be a hugetlb-specific option that pulls it in. > > Keep in mind that not everybody enables HUGETLBFS. In fact, hugetlb is > default N. It's moot to ask users whether they want to enable infra > code for a feature they aren't using, and default to Y no less. You're > regressing innocent bystanders doing this. The main reason that I added a separate config was: 1) I could see other subsystems use this. 2) The number of section flags is limited, so I wanted to put the one I added inside an option instead of always using it. If especially 2) is not a concern or can be solved differently, I'll be happy to remove the option. I don't particularly like having it, but I didn't see a better way. Let me think of a way to clean this up a little, and suggestions are welcome, of course. - Frank