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 opinions on my scheduler
Code: Select all
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M/MU d- s:- a--- C++++ UL P L++ E--- W+++ N+ w++ M- V+ PS+ Y+ PE- PGP t-- 5- X R- tv b DI-- D+ G e h! r++ y+
------END GEEK CODE BLOCK------
Yes, with that many priority levels it does consume a good amount of space. For my kernel, I only use 3 priority levels,s o I am probably going to re-implement my manager in the near future, possibly add special code to make lists depending on how many process' in each queue as well, so for example, if I have 1 high priority, and 10 normals, I might want to give the normal priorities a bit more time to run, but this is all up in the air and highly flexible. With 32 priority levels, it will start taking up a lot of space quickly, and the list will get rather complex.