RTEMS | cpukit/score/.../cpu.h: Implement _CPU_Spin_wait() (!1256)

[Gedare Bloom (@gedare)]

Gedare Bloom started a new discussion on cpukit/score/cpu/no_cpu/include/rtems/score/cpu.h: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1256#note_152197

 > + * -# **Reduced Thermal Load:** It prevents the core from wasting energy and 
 > + * generating heat on speculative execution paths that will ultimately be flushed.
 > + * -# **Shared Resource Yielding:** On SMT (Simultaneous Multithreading) architectures, 
 > + * it temporarily frees up ALUs and execution units for the sibling hardware thread.
 > + * -# **Reduced Bus Contention:** It drastically lowers the rate of memory read 
 > + * requests, preventing the polling core from saturating the memory controller.
 > + *
 > + * **Deterministic Hedged Read Library (DHRL) Context:**
 > + * In RTEMS_SMP configurations utilizing the DHRL API via the RTEMS_DHRL compiler flag, 
 > + * deterministic timing and predictable memory latency across multiple cores are paramount. 
 > + * When a core is blocked waiting for a hedged read operation to resolve or a synchronization 
 > + * flag to toggle, a standard tight loop would monopolize the shared memory bus. 
 > + * `_CPU_Spin_wait()` is utilized within DHRL polling routines to "quiet" the 
 > + * waiting core. By silencing the memory bus traffic of the blocked core, it 
 > + * guarantees that the active cores performing the critical path operations have 
 > + * unimpeded, deterministic access to maximum memory bandwidth.

Remove this block, it makes the commit depend on the DHRL library ,which it should not. anyway I don't think this adds much to this place. Maybe add the comment to where you use the `_CPU_Spin_wait()` in the  DHRL library instead.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1256#note_152197
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20260609/2e1816f4/attachment-0001.htm>