Merge request https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1164 was reviewed by Chandan U
-- Chandan U commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1164#note_147578 Thank you for taking the time to review the draft and for the feedback. I completely agree that a bitmap approach wouldn't scale for massive priority ranges like those in the EDF scheduler, and the memory overhead would be unreasonable in those cases. The reason behind choosing this option was that, Since In RTEMS (via newlib), `MQ_PRIO_MAX` is statically bounded to `32` which i confirmed by crosschecking with the newlib source file and also from my local setup. For this small, fixed range, the memory overhead is limited to an array of 32 Chain_Control structures plus the Priority_bit_map_Control, which gives us deterministic O(1) insertions. As there is an advantage of the limit of 32 on the message priority value, which doesn't pose a memory overhead as well, priority bucket + bitmap which has a constant time complexity seemed more optimal compared to the Red black tree which is O(log(n)). I also included a preprocessor guard `(#if MQ_PRIO_MAX <= 255)` so that if a system ever defines a much larger priority range, it safely falls back to the existing linear traversal implementation. I originally went down this path based on a recent Discourse discussion with Gedare and Joel, where the bitmap approach was also one of the suggestions as a good fit specifically because of this small POSIX limit [Discourse discussion](https://users.rtems.org/t/gsoc-26-lower-message-priority-range-optimization/496/3?u=chandanuvm) It would be really helpful if you could take a look at my current proposal and guide me through this. [Draft Proposal](https://docs.google.com/document/d/1WvJ4_waV9SRBtQFF5k7ljKqqKsEYgl6gm2zad5fv09g/edit?usp=drivesdk) -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1164 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
