From nobody Tue Apr 7 19:07:41 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9A00FC4332F for ; Wed, 19 Oct 2022 05:24:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229786AbiJSFYQ (ORCPT ); Wed, 19 Oct 2022 01:24:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51700 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229587AbiJSFYO (ORCPT ); Wed, 19 Oct 2022 01:24:14 -0400 Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4A36A6704D for ; Tue, 18 Oct 2022 22:24:14 -0700 (PDT) Received: by mail-oi1-x232.google.com with SMTP id u15so18079281oie.2 for ; Tue, 18 Oct 2022 22:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=M/s04qlg1QWSCwEdMmimtva0jNuFE11gbWe+BdsHkxc=; b=f8BQytgKwPpGb2OXnD4IX7LNSU+yCghwsd8w2b+gz++Apw5TfpJsvVV5uW+7lLOiSQ liV/UOZhKoZRZ01OCQZcLzJ2Pg/N1DcT/dQOSe2zHImtqCYmRdy6xREuu08r2+0tByZ6 NcNaWTNm+KlV4dMZQQCMy+/mbD/gEFJgyhltDeEijR1fjYwbAYNliQ+BnoU8zs4d0i7Z CLmAUf9g9Xh0rF2aetNaVENWc3/bqZx08TzTzFG7C7V8DZy7CcaHXXstyCbtNzRzHbld RwsHPp7sQYNer5uH0ya6MDzDcE1rf2NU7Pf6HFKrd/6ZVtbCWGKDJCkyCuXrT7c+7Nis EPjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=M/s04qlg1QWSCwEdMmimtva0jNuFE11gbWe+BdsHkxc=; b=2yRjrYfvEBVde25w0lThYApYyhpGso6OoE+7KWLRyKCa+yk0KbG8UXOVpfm1Kwys3h dfZjizzn3hSjHbLZ4cBC3zskKAnX0a6J2pzTGnulaHlaGadcjwBT1lBKgstgA1b6SQ5B Jk/KVNcyZj5glFmAovBh7R+Bo9l5TxcBnsv23YG1521sBtsJPTUBw7WfDMI6NJ1w6W2I ZFSnMil5Pn+sK8fBR1ZTT4yyHhEqasA/+BL4sE5Sl2t4QQVBT/0ZqfXd29iOf5iMEueo ksY/WqnZYtVEHyi1vdO1jsN8vV4uBP86Vm9+e3SWicRK2bNsMBnvso71qKLZ+U3VEgbK aPGw== X-Gm-Message-State: ACrzQf3rn+P/ZZFupe2ZVucAAg+MuuSZgsZGrhNsOhTqsxr5e/+U1/Un lJFOsBivjfEhbLEwbJNAI0tIC5Gv44I= X-Google-Smtp-Source: AMsMyM4B4qJ0x3yt3jX+mFE/H+yecHXk+pc+eXF+KITOlzep48yjl2SUU6MOzWdDL6vQ8et0iPGH8g== X-Received: by 2002:a05:6808:1b22:b0:355:2980:2ac8 with SMTP id bx34-20020a0568081b2200b0035529802ac8mr3158005oib.1.1666157053279; Tue, 18 Oct 2022 22:24:13 -0700 (PDT) Received: from localhost ([12.97.180.36]) by smtp.gmail.com with ESMTPSA id m67-20020aca3f46000000b00350743ac8eesm6380532oia.41.2022.10.18.22.24.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Oct 2022 22:24:12 -0700 (PDT) From: Yury Norov To: linux-kernel@vger.kernel.org, Geert Uytterhoeven , Linus Torvalds , Andy Shevchenko , Rasmus Villemoes , Andrew Morton , Stephen Rothwell , Peter Zijlstra , Thomas Gleixner , "Paul E . McKenney" , Vlastimil Babka , Dmitry Vyukov , Valentin Schneider , Sander Vanheule , Alexey Klimov , Eric Biggers Cc: Yury Norov Subject: [PATCH] cpumask: limit visibility of FORCE_NR_CPUS Date: Tue, 18 Oct 2022 22:22:00 -0700 Message-Id: <20221019052200.1604488-1-yury.norov@gmail.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" In current form, FORCE_NR_CPUS is visible to all users building their kernels, even not experts. It is also set in allmodconfig or allyesconfig, which is not a correct behavior. Suggested-by: Geert Uytterhoeven Suggested-by: Linus Torvalds Signed-off-by: Yury Norov --- lib/Kconfig | 31 ++++++++++++++++++++++++------- 1 file changed, 24 insertions(+), 7 deletions(-) diff --git a/lib/Kconfig b/lib/Kconfig index 9bbf8a4b2108..1ada12f5dda6 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -528,14 +528,31 @@ config CPUMASK_OFFSTACK them on the stack. This is a bit more expensive, but avoids stack overflow. =20 +choice + prompt "Number of CPUs detection method" + default UNFORCE_NR_CPUS + depends on SMP && EXPERT + help + Select between boot-time and compile-time detection of number + of CPUs. If it's possible to provide exact number of CPUs at + compile-time, kernel code may be optimized better. + For general-purpose kernel, choose "boot time" option. + +config UNFORCE_NR_CPUS + bool "Set number of CPUs at boot time" + help + Choose it if you build general-purpose kernel and want to rely + on kernel to detect actual number of CPUs. + config FORCE_NR_CPUS - bool "NR_CPUS is set to an actual number of CPUs" - depends on SMP - help - Say Yes if you have NR_CPUS set to an actual number of possible - CPUs in your system, not to a default value. This forces the core - code to rely on compile-time value and optimize kernel routines - better. + bool "Set number of CPUs at compile time" + help + Choose it if NR_CPUS corresponds to an actual number of + possible CPUs in your system. This forces the core code + to rely on compile-time value and optimize kernel routines + better. + +endchoice =20 config CPU_RMAP bool --=20 2.34.1