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

[Wayne Thornton (@wmthornton-dev)]

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

 > +    return sc;
 > +  }
 > +
 > +  CPU_ZERO( &cpuset );
 > +  CPU_SET( core_a, &cpuset );
 > +  sc = rtems_task_set_affinity(
 > +    dhrl_worker_a_id,
 > +    sizeof( cpu_set_t ),
 > +    &cpuset
 > +  );
 > +  if ( sc != RTEMS_SUCCESSFUL ) {
 > +    return sc;
 > +  }
 > +
 > +  // Initialize Worker B
 > +  sc = rtems_task_create(

@chris @joel Based on my understanding of the feedback and the self-contained objects documentation, the only hot path is when a user calls dhrl_fetch_data(), which locks and unlocks a mutex. If I use rtems_semaphore_obtain, I'll incur the overhead of the kernel looking up the rtems_id in a table every single time. By moving the mutex to a self-contained object rtems_mutex, I can remove that lookup overhead, making the hot path faster and more deterministic.

The thread setup dhrl_init, on the other hand, is a cold path. It runs exactly once during system startup and the performance overhead of creating a task via the Classic API there doesn't matter.

Based on that thinking, I'm considering continuing to use the Classic API (rtems_task_create and rtems_task_set_affinity) for the worker tasks and converting only the mutex to a self-contained object.

Thoughts?

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1193#note_148384
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/20260410/8ed2d401/attachment-0001.htm>