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