app: prj.conf: use trigger threshold of 1 as default#10647
app: prj.conf: use trigger threshold of 1 as default#10647kv2019i wants to merge 1 commit intothesofproject:mainfrom
Conversation
Set CONFIG_LOG_PROCESS_TRIGGER_THRESHOLD=1 as the default behaviour. Given most actions in the DSP FW happen every LL (msec) tick, having defer logic of upto 100msec in the logging subsystem is not really helpful. Logging thread should be preempted by higher priority threads in any case. This setting will cause the logger thread to be woken up (with a semaphore) every time a log entry is printed and no timer is used at all. The actual logging will not happen until logger thread gets to run, but the wakeup request is immediate. This setting works better with logging backends that have a limited internal buffer (like mtrace and Zephyr winconsole) that are commonly used with SOF targets. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
|
FYI @checkupup this might help to avoid dropped messages as well. Got the idea to revisit this setting in our default prj.conf while reviewing your zephyrproject-rtos/zephyr#105550 . If you have a piece of code (like a module init sequence) emitting a lot of logs, this can easily overwhelm backends like mtrace and winconsole where the backend has a limited buffer and the host may sleep for relative long periods of time (in terms of DSP time) between emptying the buffer. @checkupup additional buffer will help, and this PR should also show a benefit. Neither will help if DSP is continuously sending more logs than the log transport can handle, but for those case, move to DMA based logging (with probes) is the right solution. Note: keeping as draft to get some CI feedback on this before marking ready for review. |
Thanks, @kv2019i , I have already tried using the following configuration but the issue in the zephyrproject-rtos/zephyr#105550 still persists.
That's good. |
kv2019i
requested review from
dbaluta,
lbetlej,
lgirdwood,
mmaka1 and
plbossart
as code owners
|
Initial tests ok, let's mark ready for review to get wider coverage. And ack @checkupup , this won't solve issue with a burst of log messages that exceed the 4K shared mem buffer. E.g. if you output a lot of debug in module init, this will be all printed before the log thread gets to run (even with this PR) and logs will be lost. So zephyrproject-rtos/zephyr#105550 (or some other solution like DMA/probes logging, dictionary) is still needed for this type of use. |
There was a problem hiding this comment.
Pull request overview
Updates the Zephyr logging configuration to make deferred log processing wake the log thread immediately on each new log message, reducing logging latency for DSP workloads that operate on millisecond tick timing.
Changes:
- Change
CONFIG_LOG_PROCESS_TRIGGER_THRESHOLDfrom5to1to wake the log processing thread on every enqueued log entry. - Remove the explicit
CONFIG_LOG_PROCESS_THREAD_SLEEP_MS=100timer-based wakeup configuration and update the accompanying comment.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| # Wake the low-priority log thread every time new log | ||
| # messages are available |
There was a problem hiding this comment.
Minor grammar/style: consider making this a complete sentence (e.g., add a period and/or keep it on one line). Current wording/line break reads a bit awkwardly in the config comment.
| # Wake the low-priority log thread every time new log | |
| # messages are available | |
| # Wake the low-priority log thread every time new log messages are available. |
Set CONFIG_LOG_PROCESS_TRIGGER_THRESHOLD=1 as the default behaviour.
Given most actions in the DSP FW happen every LL (msec) tick, having defer logic of upto 100msec in the logging subsystem is not really helpful. Logging thread should be preempted by higher priority threads in any case.
This setting will cause the logger thread to be woken up (with a semaphore) every time a log entry is printed and no timer is used at all. The actual logging will not happen until logger thread gets to run, but the wakeup request is immediate.
This setting works better with logging backends that have a limited internal buffer (like mtrace and Zephyr winconsole) that are commonly used with SOF targets.