Chandan U commented: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5247#note_147026 Hello @gedare @joel , After studying the relevant code files and understanding the present priority bucket + bitmap implementation logic in the schedular, I've created a draft MR ([!1164](https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1164)) for POSIX priority message queue insertion/deletion algorithm optimization based on the discussions ([thread](https://users.rtems.org/t/gsoc-26-lower-message-priority-range-optimization/496)) and findings. Explanation of the draft design and Implementation: * In `coremsg.h` which consists of message queue main internal structure , * **new addn :** It extends `posix_priority` pointer , which makes the queue to optionally hold optimization state and NULL means fallback to legacy path * In `coremsgimpl.h` which consists of the prototype of internal implementation * **new addn :** * `CORE_message_queue_Posix_priority_context` structure: \- bitmap \- per-priority bitmap info \- per-priority chain buckets * declaration for `_CORE_message_queue_Enable_posix_priority_buckets() ` * fast path in pending-message retrieval using bitmap. * In `mqopen.c` which consists of POSIX specific create/open logic * **new addn** : calling the enable function for priority bucket+bitmap * In `coremsg.c` which consists of logic related to queue initialization and setup * **new addn** : implementation of the enabling function * In `coremsgflush.c` which consists of the logic to clear all the pending messages * **new addn** : flush helper for priority bucket and bitmap reset * in `coremsginsert.c` which consists of the actual O(n) algorithm , for the insertion of priority messages * **new addn** : append to corresponding bucket and set bitmap bit With this I've also created a small draft benchmark for comparing the before and after optimization paths MR (!1151) * **Logic:** Inserting same priority messages and filling the message queue to its limit, a receiver thread is called and made the queue to get free by exactly one space, then a sender is called to insert the message with same priority which is already present in the queue (to make sure that it traverses to the end of the queue) using `rtems_counter_ticks` and `rtems_counter_read()`. I would be grateful for any feedback or suggestions on the design and implementation. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5247#note_147026 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
