logging: Add CONFIG_LOG_CORE_ID_PREFIX for multicore systems#104399
Conversation
Add support for displaying the CPU core ID that generated each log message. This is particularly useful for debugging multicore embedded systems where identifying the originating core is critical. Key implementation details: - Add CONFIG_LOG_CORE_ID_PREFIX Kconfig option (depends on SMP or MP_MAX_NUM_CPUS > 1) - Capture arch_proc_id() at log message creation time to ensure the correct core ID is recorded, even when log processing happens on a different core - Add core_id field to log_msg_hdr structure - Add LOG_OUTPUT_FLAG_CORE flag (BIT 9) - Display format: "[core %d]" prefix in log output - Add log_msg_get_core_id() accessor function The core ID is captured when the log message is created (not when formatted), which is essential for deferred logging where the processing thread may run on a different core than the one that generated the log. Signed-off-by: Tomasz Leman <tomasz.m.leman@intel.com>
tmleman
force-pushed
the
topic/upstream/pr/subsys/logging/add_core_id
branch
2 times, most recently
from
887e190 to
4084ec7
Compare
Update all log_output_process() function calls to include the new core_id parameter that was added to support CONFIG_LOG_CORE_ID_PREFIX feature. The core_id parameter is set to 0 for these call sites since they don't have core ID information available. This maintains backward compatibility while adapting to the updated function signature. Affected files: - tests/subsys/logging/log_output/src/log_output_test.c - tests/subsys/logging/log_output_net/src/log_output_test.c - tests/subsys/logging/log_timestamp/src/log_timestamp_test.c Signed-off-by: Tomasz Leman <tomasz.m.leman@intel.com>
Update all log_output_process() function calls in the nRF ETR debug driver to include the new core_id parameter that was added to support the CONFIG_LOG_CORE_ID_PREFIX feature. The core_id parameter is set to 0 for all call sites in this driver since core ID information is not available from the trace/log packets being processed. This maintains backward compatibility while adapting to the updated log_output_process() function signature. Signed-off-by: Tomasz Leman <tomasz.m.leman@intel.com>
Add support for the LOG_OUTPUT_FLAG_CORE flag in the ADSP mtrace backend's format_flags() function. When CONFIG_LOG_CORE_ID_PREFIX is enabled, this allows log messages to display the originating CPU core ID as a prefix. This is particularly useful in multicore ADSP systems where deferred logging may format messages on a different core than where they were created. The core ID prefix helps identify which core generated each log message. Signed-off-by: Tomasz Leman <tomasz.m.leman@intel.com>
Add support for the LOG_OUTPUT_FLAG_THREAD flag in the ADSP mtrace backend's format_flags() function. When CONFIG_LOG_THREAD_ID_PREFIX is enabled, this allows log messages to display the thread name or ID as a prefix. This enables displaying information about running threads and their priorities, which can be useful debug information for analyzing system behavior and thread execution patterns. Signed-off-by: Tomasz Leman <tomasz.m.leman@intel.com>
tmleman
force-pushed
the
topic/upstream/pr/subsys/logging/add_core_id
branch
from
4084ec7 to
1cb79f3
Compare
|
zephyrbot
added
area: Tests
zephyrbot
requested review from
anangl,
asmellby,
bjarki-andreasen,
dcpleung,
jaz1-nordic,
kl-cruz,
lstnl,
magp-nordic,
nashif,
nika-nordic and
nordic-krch
| Enable support for prefixing log message with thread name or ID. | ||
| Thread name is used if THREAD_NAME is enabled. | ||
|
|
||
| config LOG_CORE_ID_PREFIX |
There was a problem hiding this comment.
Good idea, but it's also an unnecessary overhead for most common use cases (single core scenario in multicore system).
Open suggestion: what if we only showed the extra prefix for secondary cores logs?
There was a problem hiding this comment.
The config is n by default, so user has to actively enable it, also it depends on MP_MAX_NUM_CPUS > 1 so it can't be enabled if the platform is single core
There was a problem hiding this comment.
I said single core scenario in multicore system. In our project, our target is multicore (MP_MAX_NUM_CPUS > 1), so we actually plan to enable this Kconfig by default. However, in most of our practical use cases, only one core is enabled.
In that case, "[core 0]" is just unnecessary noise. That's why I suggested showing the prefix only for secondary cores. It identifies the secondary cores when they actually run, while keeping the primary core logs clean.
There was a problem hiding this comment.
ok, that makes sense. Not exactly related to this kconfig though, maybe note this optimization where its relevant, here maybe https://github.com/zephyrproject-rtos/zephyr/pull/104399/changes#diff-c8e20a3af13ad733ec3108e392982f24f49505cfc8c8006cbb2413608a8f59bbR331
There was a problem hiding this comment.
I understand this but I probably don't want to change it now. I considered two options for how this could be addressed and I don't like either of them. Maybe changing from [core 0] to [0] would be enough?
|
Test run in SOF: thesofproject/sof#10572 |
|
@nordic-krch @dcpleung can you look at this PR? |
7 participants
Add support for displaying CPU core ID as a prefix in log messages for multicore systems.
The implementation captures the core ID at message creation time using arch_proc_id() and stores it in the log message header.
A new runtime flag LOG_OUTPUT_FLAG_CORE allows backends to control core ID display independently of the compile-time configuration.
The configuration option CONFIG_LOG_CORE_ID_PREFIX is available only on multicore systems (depends on SMP || MP_MAX_NUM_CPUS > 1) to avoid memory overhead on single-core platforms.
Example output showing core ID prefix:
Before:
After:
Tested on Intel ADSP ACE 1.5 (MTL)