RTEMS | cpukit: Create DHRL Library for DRAM Latency Mitigation (!1193)

[Wayne Thornton (@wmthornton-dev)]

Merge request https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1193 was reviewed by Wayne Thornton

--
  
Wayne Thornton commented on a discussion on cpukit/include/rtems/dhrl.h: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1193#note_150423

 > + * @brief Deterministic Hedged Read Library (DHRL) Public API
 > + *
 > + * @note This library is explicitly constrained to x86_64/amd64 architectures.

Hi @gedare, thanks for the review.

You are correct, the current limitation is due to the inline assembly required for cache invalidation (clflush) and cycle timing (pause/rdtsc), which are currently hardcoded.

I agree that this shouldn't bottleneck the cpukit level. I will refactor the implementation to abstract those hardware-specific instructions behind architecture hooks in score/cpu/, keeping the core API clean.

However, I do want to flag a broader architectural concern. While the API will be portable, the actual efficacy of DHRL relies heavily on strict SMP core affinity and predictable memory controller behavior. On architectures with weakly ordered memory models or non-deterministic bus arbitration, a functional port might not be physically viable at the hardware level.

My plan is to define the hooks so that unsupported architectures can safely stub them out and return RTEMS_UNSATISFIED (or simply compile to a no-op fallback) to prevent unexpected hardware behavior on non-x86 targets. Thoughts?


-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1193
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/20260518/0712ef1c/attachment.htm>