casaroli opened a new pull request, #21429: URL: https://github.com/apache/nuttx/pull/21429
## Summary CHECK_BUSYWAIT() is active for SCHED_CRITMONITOR_MAXTIME_BUSYWAIT >= 0. The other CHECK_*() macros of sched_critmonitor.c (PREEMPTION, CSECTION, THREAD), the IRQ, WDOG and WQUEUE checks, SCHED_CRITMONITOR_MAXTIME_PANIC and Documentation/os/interrupts/critical_sections.rst give the warning only for a value > 0: 0 means "statistics only". With the value 0, each busy wait longer than 0 gives a warning, and the console fills with "wait for critical section or spinlock too long". This PR makes CHECK_BUSYWAIT() active only for a value > 0, as the others. ## Impact Behaviour change for SCHED_CRITMONITOR_MAXTIME_BUSYWAIT = 0 only: no more warning for each busy wait (the busy-wait statistics in procfs stay). For a value > 0 nothing changes. No API change. No documentation change: critical_sections.rst already says "> 0 to also do alert log". ## Testing qemu-armv8a:nsh (HVF) with SCHED_CRITMONITOR, ARCH_PERF_EVENTS, SCHED_CRITMONITOR_MAXTIME_CSECTION 0 and SCHED_CRITMONITOR_MAXTIME_BUSYWAIT 0 (BUSYWAIT >= 0 with CSECTION -1 does not build on master; #21426 fixes that): | test | master | this PR | |---|---|---| | boot to NSH | no: the console stops in the first busy-wait warning | yes, no warning | | ostest | not reached | exits with status 0 | Builds with -Werror (nucleo-l432kc:nsh, SCHED_CRITMONITOR, CSECTION 0): BUSYWAIT 0: OK; BUSYWAIT 100 with SCHED_CRITMONITOR_MAXTIME_PANIC: OK. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
