Posted: Thu Mar 27, 2008 11:59 am
Ready4Dis,
Your method does seem to have potential, but as it stands it uses a huge amount of global data. My kernel uses 32 priority levels, and from what I can see that would take over 2KB just for your 'MasterPriorityList'. I really like how easy it is to tell how much CPU time will be consumed by each priority level, however.
I still prefer my second method though, which only requires one extra global integer. With 32 priority levels, the bit rotations are easy, and with doubly linked lists, copying between runqueues is O(1) (and easy).
I'm not sure how it holds up in terms of CPU time distribution though. The effect is to temporarily boost the priority of all threads up to the next level (except threads which have the current max priority, which are moved down a queue); of course the priorities are not really touched, but the queues seem to rotate, so a thread is requeued in the correct relative position.
Sean
Your method does seem to have potential, but as it stands it uses a huge amount of global data. My kernel uses 32 priority levels, and from what I can see that would take over 2KB just for your 'MasterPriorityList'. I really like how easy it is to tell how much CPU time will be consumed by each priority level, however.
I still prefer my second method though, which only requires one extra global integer. With 32 priority levels, the bit rotations are easy, and with doubly linked lists, copying between runqueues is O(1) (and easy).
I'm not sure how it holds up in terms of CPU time distribution though. The effect is to temporarily boost the priority of all threads up to the next level (except threads which have the current max priority, which are moved down a queue); of course the priorities are not really touched, but the queues seem to rotate, so a thread is requeued in the correct relative position.
Sean