On Saturday 23 June 2007, Paolo Ornati wrote: > But the fact is, the "interactivity estimator" is too fragile, and when > it fails it can do much damage. > > > Fair scheduler instead: > - are robust > - provide consistent behaviour > - provide good interactivity within the bounds of fairness
Yes, this is what I have concluded from this thread. Trying to guess which tasks should have higher priority is not the right approach. It's not a CPU scheduler's business to decide about priorities. > > In my very simple test scenario the mainline scheduler > > did behave much better. > > Of course... because of the two competing processes the > "interactive" (for you) one needs 60%, that is more than it's 50% fair > share. > > The real solution is to use nice levels so the scheduler doesn't have > to guess what process is more important. Yes, this seems to be the right approach from all the opinions I've heard. > And yes, programs/distributions should set good defaults for you... and > if they don't, just complain to them :) I'm sure they'll do once a fair scheduler goes into mainline :) I guess what I was missing from the beginning is that "fair" means that the scheduler will be fair among tasks that have the same priority, but if a task has a higher priority, it _will_ get more CPU. So we'll just have to mark applications like video players, audio players or games with a high priority, others like encoders or compilers with low priority, and leave the rest (browsers, word processors, email readers, etc...) as normal priority. This way a fair scheduler would be able to give each task right amount of CPU. That sounds like a good solution to me. Thanks, Alberto. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/