From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f42.google.com (mail-ed1-f42.google.com [209.85.208.42]) (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 DAB6B2BD58A for ; Fri, 21 Nov 2025 15:52:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763740377; cv=none; b=t3HJyNAXZVcLLelZf81geP7yJy1dzNJjVamPAkA50WO2oxhbut2q+g1Wp43H7e51V3s+dBZdzPr4p0MPouO4RntQhBSkUYfAtyjRRfHhvr7YOef1XdJygJEWlMQBZLxefr6+zwiz0z963Crk/pQBkNLny5y/pglPm5mHPIrKExM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763740377; c=relaxed/simple; bh=/VY0GNvis8pdF5r928gC6dLRQAVx0gdD2FVBHB9zcOc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=baeFDNwLL2CxKKiXvv9auuhwqVodxrcYJSplO4j0Gwi6goju4DJakXiIyRax9K7M2tHJSDq/2pSdWO5eBbaH39KSxllUaPLaPMXqLN0z1BbCoGpcS9L6txM+4Nw1BO38Z7va1eGbji+TQlxEG1ajk1rv4XbDaOz2/hCvDlv3jUA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=ODywa1re; arc=none smtp.client-ip=209.85.208.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="ODywa1re" Received: by mail-ed1-f42.google.com with SMTP id 4fb4d7f45d1cf-64175dfc338so3846279a12.0 for ; Fri, 21 Nov 2025 07:52:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1763740370; x=1764345170; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Iq6QIppYBAVR1vxBCUsYMF50tPkMbF73VQScPbE3pr4=; b=ODywa1reargwbLR6e5q68toPvbzjGrdQT5rkBo4DhOld/NOI2IXWDkNdRSeZgxycM2 qY7v6HxDqyJEAUm/fojar2Ksk0jsonfuceSF+E4WjPM4O9NnCtwum43+Fc8P5UHaFSCA IPw7+DjdDLj1PWHPDS4hWlQrDS/LQbSjT33FRvQ/DZyV61U73/xR2l2wyn9B2amakvjK TZRapfeVfBfzR9ukjt/GBzJZLA0jQ4kgWHoK3sq0LykmH00TBruCAiOwCE9M5aFiU+q1 8tDzxUbNFICgvQ3ibsvwspAuBdLT7bJIdU3o7IFZSD/1YF/QVNGm/kZ8VQadE2A2Ncs1 1h2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763740370; x=1764345170; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Iq6QIppYBAVR1vxBCUsYMF50tPkMbF73VQScPbE3pr4=; b=D9ukY9jFoITuf1MyzpeGpmPfRh7cmjzy+nR9KZWH4SX6lw8CVcS75VOZUsgfNGksyE hfc6bHb9Qk7b5OEA6nAmGdpsENSJm83FBoJF6wVZxfKEHKCw4ZRwxtx5V/XAWJlrIB3U 6jQEJh/ggwEBUPmOYPkfa5PYPqHEX+0fYsTZVkwr0MVPGJL3MZVesxQvBNfHAhJxzqKZ YoXQiOfQAcAqXeqUPk7ssyL73/oOoOFgOIuHibZr4jZRzE9uMjuFtuKCoBSqHJIQELAj ee1g11823twoGuwwvYS5PJHMlh6tzw7p1jgl299U/OuLnPxz3/bu4SY/zaIeVomRfxT0 6P8Q== X-Gm-Message-State: AOJu0YwHJ69rJQtcikYt7VjdYfkPltLOWomYRHi1eEt+t+Ccm71O4OaL asqu0WRbyavrvdhoYgv5rvkmfSv/3ywL556jOtkfkkbT8y3jFsHy8F0c+qt+nIaM7Q8= X-Gm-Gg: ASbGnctecKcPqdETSemneGlQSptOKJmlWPMgiLiEvvHO2Ro6yTUOtRKr6vjWhmZUHhm O7+8ySeqmJJmxmZNQMlDHaYctGRUzJlBWyfvJtjfrAk5RrHdwW1XbxL2240VBCI3xi1XWhoqKqa Dvt9OzVEG3ovStPYyd6oazi9vt4mNuOH5f1Nn76tyHp+4MXgUPCG6PVH3CNMuup6LJJFLX7qZcZ f3V7IRbE1ieAJgxEFNfzh0fGIB36QNrvbaooqbWEQArHpACtleRPC1WHJ8NpklrYBERmazhQuGN 2mV5m8raYCL8tqmAlzISXaBGOVQm5ez7kx8VgNuRv6RBNYjBK1g5RIK+Qxim4IJFSKsXkplgpit XPn3RIaOJ+i4zPjyuasXgtuRS/nnkq04JegyRwiEOsBoibDe/wfXovOU0ZOraEYaAgFTarI/RYK kYVpZCeVVxhSbQcg== X-Google-Smtp-Source: AGHT+IHA3tAsotl6/sXjh5QRifRrjoT73SH4Q+GOKbSSPU0K4leTbGJFI4XMHby+HO2mUaI5fF2NSA== X-Received: by 2002:a17:907:72d1:b0:b73:5c12:3f8a with SMTP id a640c23a62f3a-b767158cbe7mr322050166b.18.1763740370378; Fri, 21 Nov 2025 07:52:50 -0800 (PST) Received: from pathway.suse.cz ([176.114.240.130]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b7654d7a0f4sm496090666b.26.2025.11.21.07.52.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Nov 2025 07:52:49 -0800 (PST) Date: Fri, 21 Nov 2025 16:52:48 +0100 From: Petr Mladek To: Chris Down Cc: linux-kernel@vger.kernel.org, Greg Kroah-Hartman , Sergey Senozhatsky , Steven Rostedt , John Ogness , Geert Uytterhoeven , Tony Lindgren , kernel-team@fb.com Subject: Re: [PATCH v7 11/13] printk: docs: Add comprehensive guidance for per-console loglevels Message-ID: References: <60de5c9e249579d8d4e5a9423067157a462eb763.1763492585.git.chris@chrisdown.name> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <60de5c9e249579d8d4e5a9423067157a462eb763.1763492585.git.chris@chrisdown.name> On Wed 2025-11-19 03:08:01, Chris Down wrote: > The per-console loglevel feature documentation could use some practical > guidance. This commit adds: > > - Examples section covering runtime configuration, effective loglevel > checking, and boot-time configuration > - Common use case demonstrating high-performance netconsole with quiet > serial console fallback > - Performance impact section explaining how per-console loglevels reduce > latency by filtering messages before slow console writes > - Troubleshooting section addressing common issues like messages not > appearing, loglevel constraints, and minimum console loglevel I would remove the section about the "minimum console loglevel", see below. > - Edge cases section documenting behavior with concurrent writes, > console unregistration, and global loglevel changes > > The guidance interleaves advice about many parts of this patchset, so > let's have it in a distinct commit. > > This documentation will help users understand how to effectively use and > debug per-console loglevels. > > +Performance Impact > +------------------ > + > +When a console has a higher (less verbose) loglevel than the global level, > +messages that would normally be sent to that console are filtered out before > +the console write callback is invoked. This eliminates the latency that would > +be incurred by writing those messages to slow consoles (e.g., serial ports). The above section is either confusing or wrong ;-) A higher loglevel number means that more loglevel are allowed and the console is more verbose. > +For example, setting a serial console to WARN level (4) while keeping > +netconsole at INFO level (6) prevents INFO and NOTICE messages from being > +written to the slow serial port, reducing application stalls during verbose > +logging periods. > + > +Serial console writes can take tens of milliseconds per message. During > +periods of heavy logging (e.g., during network debugging or block I/O tracing), > +this can cause significant application-level stalls. By setting a higher > +per-console loglevel for the serial console, you can avoid these stalls while > +still capturing all messages on faster consoles like netconsole. This is true for legacy consoles. The drivers converted to nbcon API offload messages to a kthread when the system is working properly. It prevents the stalls but the console might be far behind and the oldest messages can get lost when the log buffer is full. And the stalls are still possible when the system enters an emergency, e.g. Oops, still, or WARN(). I think how to update this section. I would write something like: Performance Impact ------------------ Kernel messages used to be flushed to the consoles immediately even from a context where the scheduling is not possible. It increases a chance to see the messages even when the system is in a bad state. But it might cause significant application-level stalls (e.g., during network debugging or block I/O tracing). Note that serial console writes can take tens of milliseconds per message. The console drivers are being converted to nbcon API (the letter 'N' in /proc/consoles output). These drivers write the messages in a dedicated kthreads when the system is working properly. It reduces the risk of stalls. But the messages are still flushed immediately when the system detects an emergency situation, for example Oops, stall, or a warning. Also the messages can get lost when the ring buffer is full and the console driver is far behind with flushing. For example, setting a serial console to WARN level (4) while keeping netconsole at INFO level (6) prevents INFO and NOTICE messages from being written to the slow serial port. It reduces the risk of application stalls or message loses during verbose logging periods. > +Setting below minimum_console_loglevel fails > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > + > +If you get an error when trying to set a loglevel, check the system-wide > +minimum:: > + > + cat /proc/sys/kernel/console_loglevel > + > +Per-console loglevels cannot be set below this minimum. This is a safety > +feature to ensure critical messages are always visible. This section is not valid anymore. I think that it is from an earlier version of the patchset where the per-console loglevel only allowed to reduce the verbosity. But this version allows to simply replace the global setting to any valid value. Or the section was about the "minimum_console_loglevel" variable. But it is basically hardcoded to 1. I doubt that anyone modifies it in practice. I would just remove this section.. Best Regards, Petr