2009/11/27 Mikhail Panasyuk <otoko@xxxxxxxxx>: > My conclusion is: you can't use fair schedulers in Haiku untill all > priorities of system threads redefined. Or you should somehow protect > important system threads from being cut off. Or implement some intelligent > mechanism which would change priorities of CPU-hungry threads on-the-fly. Or > give up "some" fairness. Hello, Mikhail, First of all, I'm really glad that you found the time to keep hacking on the scheduler! But regarding your last email, and particularly the snippet I quoted above, I don't think you've reached a valid conclusion... :) I believe that the issues of opportunity to execute and spent CPU time are fully orthogonal. Most "fair" CPU schedulers so far only care about the latter. I'd like you to do a little experiment, please. See what happens if you only care about the former (not quite, see below). Change your fairness criteria to mean not how much CPU time a thread is allowed to spend (based on some factor involving its priority) to mean how many times it is allowed to execute given the ratio between its priority and the priority of all other threads on the system. This is the cornerstone of my scheduling model. Have a global priority accumulator which gets increased every time a thread is spawned by said thread priority, and decreased when it dies. Have your scheduler pick a given thread thread thread_priority times out of cumulative_priority in the time span of cumulative_priority scheduling rounds. Now, if you'd like to improve the odds for a thread that uses little CPU time to be picked more often, you might want to change the scheduling logic so that (thread.)priority is never changed and scheduling decisions are always based on next_priority, which would then represent the adjusted priority based on this boosting criteria. Boy, talking about schedulers always gets my nerdy side all fired up. :D Can't wait for the holidays so I can go back to hacking! Cheers, A.