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

Wayne Thornton (@wmthornton-dev) gitlab at rtems.org
Tue May 19 23:07:52 UTC 2026




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

 > +/* SPDX-License-Identifier: BSD-2-Clause */
 > +
 > +/**
 > + * @file
 > + *
 > + * @brief Deterministic Hedged Read Library (DHRL) Public API
 > + *
 > + * @note This library is explicitly constrained to x86_64/amd64 architectures.

@gedare That makes complete sense. I've updated the implementation to drop the custom _DHRL prefixes and am now using the existing generic RTEMS cache management APIs (rtems_cache_invalidate_multiple_data_lines) as you suggested. I've also re-mapped the pipeline stall logic to a generic _CPU_Pause_speculation() pattern to align with standard RTEMS conventions and placed that in the `score/cpu.h` header file for the x86_64 architecture. (This should be done for every BSP that is being compiled but is not required for merge)

Regarding the hardware requirements, I am drafting a new documentation section outlining exactly what an architecture needs to support the DHRL API (SMP, generic cache invalidation, pipeline speculation control, and multi-channel interleaving). I will include this in an appropriate patch set. Does this look better for merge?

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1193#note_150564
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/20260519/e87a9ea8/attachment.htm>


More information about the bugs mailing list