Message ID | 20240207171020.41036-2-yoann.congal@smile.fr |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-56806-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:168b:b0:106:860b:bbdd with SMTP id ma11csp2376505dyb; Wed, 7 Feb 2024 09:12:31 -0800 (PST) X-Google-Smtp-Source: AGHT+IHcnL/SbSYxtlDzAcgm33Qm31QsbunnqJDqTUY2TIjK+oM1NfTLB7JEUkJGzv0nt+CH0tZA X-Received: by 2002:a05:651c:556:b0:2d0:b663:f053 with SMTP id q22-20020a05651c055600b002d0b663f053mr5973834ljp.22.1707325951435; Wed, 07 Feb 2024 09:12:31 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707325951; cv=pass; d=google.com; s=arc-20160816; b=gKodI2RGIVJjRHxVN6Gnk7GQ6pM23Vot+X5EgUEeBG3fUQnHeZkxILBf8VQ7mwn5/z /oZJdh/O+soU5EiMprJSrBqljPjMWtj/N062S0gqmy13NGyK5F3xMB8uLMGpDvGSgewy O1nbVfWvMv3le3nKVciOXMTlg0FPe/9+mPz4NMYwna+M+wJLLcVGJZYiY6JfzdI9p3bL GoNX0I36Bj3rYrEurvF2nYTnYChd1pBZnkdncrEUdSqfUCIegoUDuFylLpaqKl0IQlHl jV5R3+wFR7Kinx1PQodkqWjK+aYPXRyXTTbBnTWcCPWfoAb7c4xB8yxMM08krawQjXM+ cHSw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=JGAprqtgwfmvAPo8XwmHq4MOLLyHp0qoLOC+fnp28mc=; fh=pg/F0ZD5jsyhYYf6tU8zUI6qVAQAhTHEjdo2K4BfezU=; b=Eja6HL8tSW/YN5C7c6T1/y3p5Z3PclTKlVFCBNOE60L8WY/t4IaoNiHNsmTDWDKDjD rVAyMAJuxQGZm5B4xTXa8yedzygzzHVRkmax1iGDyo/OWTAxSEgmQf9ehcu0H3ipivvu bLnatgQg/91cUGVvTdhvKEIfaalKVhugREk0obw8abVQy5Hdom+/oS1qTnZ1h8d7fn9j QVzStg6bx3EWBQiweMisSens4JOg7nJbqMdy50ru/0dhyKy9NQtpeb7FFNPGWgwh5h5p eMQxjDIBUg9RGKnQ7OlX/kiz4/RLzseegIbwJvThlyUjs4/DM6mu/WRYltT8gmMmb0tx 3gug==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@smile-fr.20230601.gappssmtp.com header.s=20230601 header.b=JyCIYQbZ; arc=pass (i=1 spf=pass spfdomain=smile.fr dkim=pass dkdomain=smile-fr.20230601.gappssmtp.com dmarc=pass fromdomain=smile.fr); spf=pass (google.com: domain of linux-kernel+bounces-56806-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-56806-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=smile.fr X-Forwarded-Encrypted: i=2; AJvYcCXHWdIqyH9Jvoa3i4af7n0hpVG2vQJ4JA2nK/C13eCbggUwpZVuK+W24QYEiRvZ7gEm9QZOnoQvy0C6fP1VsOrdugK7tg== Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id i11-20020a05640242cb00b00560da6f316bsi1109747edc.175.2024.02.07.09.12.31 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Feb 2024 09:12:31 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-56806-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@smile-fr.20230601.gappssmtp.com header.s=20230601 header.b=JyCIYQbZ; arc=pass (i=1 spf=pass spfdomain=smile.fr dkim=pass dkdomain=smile-fr.20230601.gappssmtp.com dmarc=pass fromdomain=smile.fr); spf=pass (google.com: domain of linux-kernel+bounces-56806-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-56806-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=smile.fr Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id E1A6B1F21BEC for <ouuuleilei@gmail.com>; Wed, 7 Feb 2024 17:12:20 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id C88C484FC7; Wed, 7 Feb 2024 17:10:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=smile-fr.20230601.gappssmtp.com header.i=@smile-fr.20230601.gappssmtp.com header.b="JyCIYQbZ" Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) (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 4989282886 for <linux-kernel@vger.kernel.org>; Wed, 7 Feb 2024 17:10:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.41 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707325852; cv=none; b=M9GZmDmiZJa5eU9q8/iNSjVcoIGu5LWZqBk9We3dbVyZ59mAl2MPcDn68T138GoaIVm5efaT1tghzh1Ugt+SGCOhYIxc4YnfIK0oaKzKkJKa5exDAniv3Lm/UdIkL8qLdTsZhdrjC41ijustgFEmR2ZuZy0EgYXm9Gd/D/hH/ec= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707325852; c=relaxed/simple; bh=PZg3QWq+/GKgfZZA2qyqx39P/kRDLKfoOfmCw8uE3uc=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=auRKWFnEWzZcwXgeTZlnyymGg26tqYFPKPwY/nK7V8MQwS5c2sCSPykpnMj74GMM4c7baNoHg0n3GSwto9Pyij5qVsSdUHSroV59B7jTGDsNeBikwxhQs1YTRQFTxyErKsW+Y01u16rfRJN53BaNqfJ0DxCNpMauMg5F/SQcwSw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=smile.fr; spf=pass smtp.mailfrom=smile.fr; dkim=pass (2048-bit key) header.d=smile-fr.20230601.gappssmtp.com header.i=@smile-fr.20230601.gappssmtp.com header.b=JyCIYQbZ; arc=none smtp.client-ip=209.85.128.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=smile.fr Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=smile.fr Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-40fc549ab9bso7722085e9.0 for <linux-kernel@vger.kernel.org>; Wed, 07 Feb 2024 09:10:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smile-fr.20230601.gappssmtp.com; s=20230601; t=1707325847; x=1707930647; 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=JGAprqtgwfmvAPo8XwmHq4MOLLyHp0qoLOC+fnp28mc=; b=JyCIYQbZG3crh+1P4QYiSzc1BeeDI2f25cbQj9t9pn8weFA8c76ctON0v31zib14uj UIjYGm2vZo0BVTOVvW8AI5Ia1Uk0TU/p7I/RrIX/1IILeKzuGdUx2IKVlPFTCZOPmnme yJshfaDn79tPPU/2m6gAlWOp4vHffwxjDp/2sSh4yvbHdIzZtazmr5Rr84gOSWZKXnK5 3kDZRq4McbOIp5IweafGlu5Sx99iuDukod63FHf8KJ9df1cQ0V99I3xyYvFCDVv109Nn VbxVlWXkxxVjkOefmxsPJHkWfeM3VByI5dOtQ0PLIIvE0ivD5BZuSbyS0QGZEUYmDogn 7Z9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707325847; x=1707930647; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JGAprqtgwfmvAPo8XwmHq4MOLLyHp0qoLOC+fnp28mc=; b=v2K06m6fv077Se481Vi42VV+VCPQXtkQ06bWwN4Tw0yyo4A389fpGSPj6WNJskTPev CFE8/5EmsZbrvAt7xB6jew//ER9hsW4MSHsaN8vYirkz3UHeyyulkgjUNGyF+cFiGp7B ermUiGIS5ZPMCSurLtha6Hon3dFfYrOvL48vybQvsFnufpRk546r4grdT/xW/zxnbnYW aacAUYzELUhF8/FGjyF/LwtwkMZ7RUnpPQE2uGtJ1L37Op0bWpounFGy790F5WHZ9LW5 Io0YQ5Ks19t5LOyvKRuvJA4A+RLbUbCbB+xrwo6bNVo3xRqrhuTJ9zSNCv1pQ7qr+7QL gqkA== X-Gm-Message-State: AOJu0YxmPb+EwIZWxdeCVh7SvBwvzJJdaS5YOPOaJILZLuPzD2lhOyU/ ch6D9t9KUaqF2HPv133fJxdiPKb7KnZjXFhaJdBVTI3ZOJ2xta6poZEZlL8BMb4= X-Received: by 2002:a5d:598a:0:b0:33b:47cf:323b with SMTP id n10-20020a5d598a000000b0033b47cf323bmr5501964wri.9.1707325847517; Wed, 07 Feb 2024 09:10:47 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCWEqlBZgcgI5parjnRecsBfl/eRmycNK81pNWgTPMfS9d0gU9ZbfNFk6VhItAGJcFz4zedSglkdiAwV/NkpH32LZn4+mdvCOVkSk3xKDFSkmOA//4E3CpwlI7Bv/q+u/R/wBi06sC58B6mzWCCa9v/uGvWFnW2Dbse2R18e6VZCIlsrz219Rz8FxnnmiEQtSulxEbCYGs2BEhM4z50qIF1LWFl6oBkDnYkIkY6civz4b5VkvzRNaom+0onifvsdvBWS1+uKLHWov3f9OEPEZsJTdX3WHAFfRnSKtxQJQzsSBgjiNJQxhT27Wd4t8eNbz+15cYKj8rsIsroajY1eZ/Q/vV4rn+5/BfBcz+7HwZFUqASVDgoUtTlTknzfDJnbXTz/c2MzKcN26UQrKucjFhvOWfZAdWC/Rga2cLX4XbABIR2hUkea4D59DfoKYrx+uJyIgQQdifyUxvNW9/8GRgQIFXf0RTo4o31uphHDKjMavVPXEMqvbdTGJ2iTR3DfmBZazF6s4afXnlv9diteyADwbbDK643fgeeMLB4x188rYPURQ88gKj0vXFsazYtITvfQI8HJ7X8O1N/LpZv1xoicOZr6qrrNhOsERZrKFLSQCxF6TDxqrvZT4M7bvX0jmGY7kgRAds13Hfsq+sbwL1aDwt2HRMunVYdElP6MennipwO6pALIkL7xYcPMHHDIGNlRAfufNNq4tY8/xLgyM0A+aw2coGmRi0NauR0hM0u4P9Cv5gBl9UoXe+926ef1hhSHyFbExYAsQBEq2udQ9j/39TWb5YKqq0wyaahO93YXX5Uql9kJod+G6U4fRmFfOQ== Received: from P-ASN-ECS-830T8C3.idf.intranet (static-css-ccs-204145.business.bouyguestelecom.com. [176.157.204.145]) by smtp.gmail.com with ESMTPSA id u14-20020a05600c19ce00b0040fdf2832desm2645584wmq.12.2024.02.07.09.10.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Feb 2024 09:10:46 -0800 (PST) From: Yoann Congal <yoann.congal@smile.fr> To: linux-fsdevel@vger.kernel.org, linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org, x86@kernel.org Cc: =?utf-8?q?Andr=C3=A9_Almeida?= <andrealmeid@igalia.com>, Borislav Petkov <bp@alien8.de>, Darren Hart <dvhart@infradead.org>, Dave Hansen <dave.hansen@linux.intel.com>, Davidlohr Bueso <dave@stgolabs.net>, Geert Uytterhoeven <geert@linux-m68k.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, "H . Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>, Jiri Slaby <jirislaby@kernel.org>, John Ogness <john.ogness@linutronix.de>, Josh Triplett <josh@joshtriplett.org>, Masahiro Yamada <masahiroy@kernel.org>, Matthew Wilcox <willy@infradead.org>, Peter Zijlstra <peterz@infradead.org>, Petr Mladek <pmladek@suse.com>, Sergey Senozhatsky <senozhatsky@chromium.org>, Steven Rostedt <rostedt@goodmis.org>, Thomas Gleixner <tglx@linutronix.de>, Willem de Bruijn <willemdebruijn.kernel@gmail.com>, Yoann Congal <yoann.congal@smile.fr>, Vegard Nossum <vegard.nossum@oracle.com> Subject: [PATCH v5 1/3] printk: Fix LOG_CPU_MAX_BUF_SHIFT when BASE_SMALL is enabled Date: Wed, 7 Feb 2024 18:10:18 +0100 Message-Id: <20240207171020.41036-2-yoann.congal@smile.fr> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240207171020.41036-1-yoann.congal@smile.fr> References: <20240207171020.41036-1-yoann.congal@smile.fr> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1790261016506081563 X-GMAIL-MSGID: 1790261016506081563 |
Series |
printk: CONFIG_BASE_SMALL fix for LOG_CPU_MAX_BUF_SHIFT and removal of CONFIG_BASE_FULL
|
|
Commit Message
Yoann Congal
Feb. 7, 2024, 5:10 p.m. UTC
LOG_CPU_MAX_BUF_SHIFT default value depends on BASE_SMALL: config LOG_CPU_MAX_BUF_SHIFT default 12 if !BASE_SMALL default 0 if BASE_SMALL But, BASE_SMALL is a config of type int and "!BASE_SMALL" is always evaluated to true whatever is the value of BASE_SMALL. This patch fixes this by using the correct conditional operator for int type : BASE_SMALL != 0. Note: This changes CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 to CONFIG_LOG_CPU_MAX_BUF_SHIFT=0 for BASE_SMALL defconfigs, but that will not be a big impact due to this code in kernel/printk/printk.c: /* by default this will only continue through for large > 64 CPUs */ if (cpu_extra <= __LOG_BUF_LEN / 2) return; Systems using CONFIG_BASE_SMALL and having 64+ CPUs should be quite rare. John Ogness <john.ogness@linutronix.de> (printk reviewer) wrote: > For printk this will mean that BASE_SMALL systems were probably > previously allocating/using the dynamic ringbuffer and now they will > just continue to use the static ringbuffer. Which is fine and saves > memory (as it should). Petr Mladek <pmladek@suse.com> (printk maintainer) wrote: > More precisely, it allocated the buffer dynamically when the sum > of per-CPU-extra space exceeded half of the default static ring > buffer. This happened for systems with more than 64 CPUs with > the default config values. Signed-off-by: Yoann Congal <yoann.congal@smile.fr> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Closes: https://lore.kernel.org/all/CAMuHMdWm6u1wX7efZQf=2XUAHascps76YQac6rdnQGhc8nop_Q@mail.gmail.com/ Reported-by: Vegard Nossum <vegard.nossum@oracle.com> Closes: https://lore.kernel.org/all/f6856be8-54b7-0fa0-1d17-39632bf29ada@oracle.com/ Fixes: 4e244c10eab3 ("kconfig: remove unneeded symbol_empty variable") --- v3->v4: * Fix BASE_SMALL usage instead of switching to BASE_FULL because BASE_FULL will be removed in the next patches of this series. --- init/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Comments
On Thu, Feb 8, 2024 at 2:10 AM Yoann Congal <yoann.congal@smile.fr> wrote: > > LOG_CPU_MAX_BUF_SHIFT default value depends on BASE_SMALL: > config LOG_CPU_MAX_BUF_SHIFT > default 12 if !BASE_SMALL > default 0 if BASE_SMALL > But, BASE_SMALL is a config of type int and "!BASE_SMALL" is always > evaluated to true whatever is the value of BASE_SMALL. > > This patch fixes this by using the correct conditional operator for int > type : BASE_SMALL != 0. > > Note: This changes CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 to > CONFIG_LOG_CPU_MAX_BUF_SHIFT=0 for BASE_SMALL defconfigs, but that will > not be a big impact due to this code in kernel/printk/printk.c: > /* by default this will only continue through for large > 64 CPUs */ > if (cpu_extra <= __LOG_BUF_LEN / 2) > return; > Systems using CONFIG_BASE_SMALL and having 64+ CPUs should be quite > rare. > > John Ogness <john.ogness@linutronix.de> (printk reviewer) wrote: > > For printk this will mean that BASE_SMALL systems were probably > > previously allocating/using the dynamic ringbuffer and now they will > > just continue to use the static ringbuffer. Which is fine and saves > > memory (as it should). > > Petr Mladek <pmladek@suse.com> (printk maintainer) wrote: > > More precisely, it allocated the buffer dynamically when the sum > > of per-CPU-extra space exceeded half of the default static ring > > buffer. This happened for systems with more than 64 CPUs with > > the default config values. > > Signed-off-by: Yoann Congal <yoann.congal@smile.fr> > Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> > Closes: https://lore.kernel.org/all/CAMuHMdWm6u1wX7efZQf=2XUAHascps76YQac6rdnQGhc8nop_Q@mail.gmail.com/ > Reported-by: Vegard Nossum <vegard.nossum@oracle.com> > Closes: https://lore.kernel.org/all/f6856be8-54b7-0fa0-1d17-39632bf29ada@oracle.com/ > Fixes: 4e244c10eab3 ("kconfig: remove unneeded symbol_empty variable") > All the Reviewed-by tags are dropped every time, annoyingly. This is equivalent to v4, which had these tags: Reviewed-by: Petr Mladek <pmladek@suse.com> Reviewed-by: Masahiro Yamada <masahiroy@kernel.org> > --- > v3->v4: > * Fix BASE_SMALL usage instead of switching to BASE_FULL because > BASE_FULL will be removed in the next patches of this series. > --- > init/Kconfig | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/init/Kconfig b/init/Kconfig > index deda3d14135bb..d50ebd2a2ce42 100644 > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -734,8 +734,8 @@ config LOG_CPU_MAX_BUF_SHIFT > int "CPU kernel log buffer size contribution (13 => 8 KB, 17 => 128KB)" > depends on SMP > range 0 21 > - default 12 if !BASE_SMALL > - default 0 if BASE_SMALL > + default 0 if BASE_SMALL != 0 > + default 12 > depends on PRINTK > help > This option allows to increase the default ring buffer size > -- > 2.39.2 > > -- Best Regards Masahiro Yamada
Le 11/02/2024 à 00:41, Masahiro Yamada a écrit : > On Thu, Feb 8, 2024 at 2:10 AM Yoann Congal <yoann.congal@smile.fr> wrote: >> >> LOG_CPU_MAX_BUF_SHIFT default value depends on BASE_SMALL: >> config LOG_CPU_MAX_BUF_SHIFT >> default 12 if !BASE_SMALL >> default 0 if BASE_SMALL >> But, BASE_SMALL is a config of type int and "!BASE_SMALL" is always >> evaluated to true whatever is the value of BASE_SMALL. >> >> This patch fixes this by using the correct conditional operator for int >> type : BASE_SMALL != 0. >> >> Note: This changes CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 to >> CONFIG_LOG_CPU_MAX_BUF_SHIFT=0 for BASE_SMALL defconfigs, but that will >> not be a big impact due to this code in kernel/printk/printk.c: >> /* by default this will only continue through for large > 64 CPUs */ >> if (cpu_extra <= __LOG_BUF_LEN / 2) >> return; >> Systems using CONFIG_BASE_SMALL and having 64+ CPUs should be quite >> rare. >> >> John Ogness <john.ogness@linutronix.de> (printk reviewer) wrote: >>> For printk this will mean that BASE_SMALL systems were probably >>> previously allocating/using the dynamic ringbuffer and now they will >>> just continue to use the static ringbuffer. Which is fine and saves >>> memory (as it should). >> >> Petr Mladek <pmladek@suse.com> (printk maintainer) wrote: >>> More precisely, it allocated the buffer dynamically when the sum >>> of per-CPU-extra space exceeded half of the default static ring >>> buffer. This happened for systems with more than 64 CPUs with >>> the default config values. >> >> Signed-off-by: Yoann Congal <yoann.congal@smile.fr> >> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> >> Closes: https://lore.kernel.org/all/CAMuHMdWm6u1wX7efZQf=2XUAHascps76YQac6rdnQGhc8nop_Q@mail.gmail.com/ >> Reported-by: Vegard Nossum <vegard.nossum@oracle.com> >> Closes: https://lore.kernel.org/all/f6856be8-54b7-0fa0-1d17-39632bf29ada@oracle.com/ >> Fixes: 4e244c10eab3 ("kconfig: remove unneeded symbol_empty variable") >> > > > > All the Reviewed-by tags are dropped every time, annoyingly. Hi! Was I supposed to gather these tags from patch version N to patch version N+1? In that case, I'm sorry, I did not know that :-/ Patch 1/3 is exactly the same but patch 2/3 is equivalent but different. Is there a rule written somewhere about when carrying the tags across revision and when not? (I could not find it) > This is equivalent to v4, which had these tags: > > Reviewed-by: Petr Mladek <pmladek@suse.com> > Reviewed-by: Masahiro Yamada <masahiroy@kernel.org> Thanks a lot! > >> --- >> v3->v4: >> * Fix BASE_SMALL usage instead of switching to BASE_FULL because >> BASE_FULL will be removed in the next patches of this series. >> --- >> init/Kconfig | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/init/Kconfig b/init/Kconfig >> index deda3d14135bb..d50ebd2a2ce42 100644 >> --- a/init/Kconfig >> +++ b/init/Kconfig >> @@ -734,8 +734,8 @@ config LOG_CPU_MAX_BUF_SHIFT >> int "CPU kernel log buffer size contribution (13 => 8 KB, 17 => 128KB)" >> depends on SMP >> range 0 21 >> - default 12 if !BASE_SMALL >> - default 0 if BASE_SMALL >> + default 0 if BASE_SMALL != 0 >> + default 12 >> depends on PRINTK >> help >> This option allows to increase the default ring buffer size >> -- >> 2.39.2 >> >> > > > -- > Best Regards > Masahiro Yamada
On Tue, Feb 13, 2024 at 4:01 AM Yoann Congal <yoann.congal@smile.fr> wrote: > > > > Le 11/02/2024 à 00:41, Masahiro Yamada a écrit : > > On Thu, Feb 8, 2024 at 2:10 AM Yoann Congal <yoann.congal@smilefr> wrote: > >> > >> LOG_CPU_MAX_BUF_SHIFT default value depends on BASE_SMALL: > >> config LOG_CPU_MAX_BUF_SHIFT > >> default 12 if !BASE_SMALL > >> default 0 if BASE_SMALL > >> But, BASE_SMALL is a config of type int and "!BASE_SMALL" is always > >> evaluated to true whatever is the value of BASE_SMALL. > >> > >> This patch fixes this by using the correct conditional operator for int > >> type : BASE_SMALL != 0. > >> > >> Note: This changes CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 to > >> CONFIG_LOG_CPU_MAX_BUF_SHIFT=0 for BASE_SMALL defconfigs, but that will > >> not be a big impact due to this code in kernel/printk/printk.c: > >> /* by default this will only continue through for large > 64 CPUs */ > >> if (cpu_extra <= __LOG_BUF_LEN / 2) > >> return; > >> Systems using CONFIG_BASE_SMALL and having 64+ CPUs should be quite > >> rare. > >> > >> John Ogness <john.ogness@linutronix.de> (printk reviewer) wrote: > >>> For printk this will mean that BASE_SMALL systems were probably > >>> previously allocating/using the dynamic ringbuffer and now they will > >>> just continue to use the static ringbuffer. Which is fine and saves > >>> memory (as it should). > >> > >> Petr Mladek <pmladek@suse.com> (printk maintainer) wrote: > >>> More precisely, it allocated the buffer dynamically when the sum > >>> of per-CPU-extra space exceeded half of the default static ring > >>> buffer. This happened for systems with more than 64 CPUs with > >>> the default config values. > >> > >> Signed-off-by: Yoann Congal <yoann.congal@smile.fr> > >> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> > >> Closes: https://lore.kernel.org/all/CAMuHMdWm6u1wX7efZQf=2XUAHascps76YQac6rdnQGhc8nop_Q@mail.gmail.com/ > >> Reported-by: Vegard Nossum <vegard.nossum@oracle.com> > >> Closes: https://lore.kernel.org/all/f6856be8-54b7-0fa0-1d17-39632bf29ada@oracle.com/ > >> Fixes: 4e244c10eab3 ("kconfig: remove unneeded symbol_empty variable") > >> > > > > > > > > All the Reviewed-by tags are dropped every time, annoyingly. > > Hi! > > Was I supposed to gather these tags from patch version N to patch version N+1? > In that case, I'm sorry, I did not know that :-/ > Patch 1/3 is exactly the same but patch 2/3 is equivalent but different. Is there a rule written somewhere about when carrying the tags across revision and when not? (I could not find it) I do not know any written rules either. In my experience, people carry tags when changes since the previous version are small.
diff --git a/init/Kconfig b/init/Kconfig index deda3d14135bb..d50ebd2a2ce42 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -734,8 +734,8 @@ config LOG_CPU_MAX_BUF_SHIFT int "CPU kernel log buffer size contribution (13 => 8 KB, 17 => 128KB)" depends on SMP range 0 21 - default 12 if !BASE_SMALL - default 0 if BASE_SMALL + default 0 if BASE_SMALL != 0 + default 12 depends on PRINTK help This option allows to increase the default ring buffer size