During performance analysis of console subsystem latency, I discovered that netconsole registers console handlers even when no active targets exist. These orphaned console handlers are invoked on every printk() call, get the lock, iterate through empty target lists, and consume CPU cycles without performing any useful work.
This patch series addresses the inefficiency by: 1. Implementing dynamic console registration/unregistration based on target availability, ensuring console handlers are only active when needed 2. Adding automatic cleanup of unused console registrations when targets are disabled or removed 3. Extending the selftest suite to cover non-extended console format, which was previously untested The optimization reduces printk() overhead by eliminating unnecessary function calls and list traversals when netconsole targets are not configured, improving overall system performance during heavy logging scenarios. --- Changes in v3: - Set CON_ENABLED before re-enabling the console, to fix a selftest that was failing, as reported by Jakub on v2. - Link to v2: https://lore.kernel.org/r/20250602-netcons_ext-v2-0-ef88d9993...@debian.org Changes in v2: - Added selftests to test the new mechanism - Unregister the console if the last target got disabled - Sending to net-next instead of net (Jakub) - Link to v1: https://lore.kernel.org/r/20250528-netcons_ext-v1-1-69f71e404...@debian.org --- Breno Leitao (4): netconsole: Only register console drivers when targets are configured netconsole: Add automatic console unregistration on target removal selftests: netconsole: Do not exit from inside the validation function selftests: netconsole: Add support for basic netconsole target format drivers/net/netconsole.c | 67 +++++++++++++++++++--- .../selftests/drivers/net/lib/sh/lib_netcons.sh | 27 +++++++-- .../testing/selftests/drivers/net/netcons_basic.sh | 50 ++++++++++------ 3 files changed, 112 insertions(+), 32 deletions(-) --- base-commit: 2c7e4a2663a1ab5a740c59c31991579b6b865a26 change-id: 20250528-netcons_ext-572982619bea Best regards, -- Breno Leitao <lei...@debian.org>
