Ingo Molnar wrote: > * Peter Williams wrote: > > >>The problem: >> >>The current scheduler implementation maps 40 nice values and 10 bonus >>values into only 40 priority slots on the run queues. This results in >>the dynamic priorities of tasks at either end of the nice scale being >>squished up. E.g. all tasks with nice in the range -20 to -16 and the >>maximum of 10 bonus points will end up with a dynamic priority of >>MAX_RT_PRIO and all tasks with nice in the range 15 to 19 and no bonus >>points will end up with a dynamic priority of MAX_PRIO - 1. >> >>Although the fact that niceness is primarily implemented by time slice >>size means that this will have little or no adverse effect on the long >>term allocation of CPU resources due to niceness, it could adversely >>effect latency as it will interfere with preemption. > > > this property of the priority distribution was intentional from me, i > wanted to have an easy way to test 'no priority boosting downwards' > (nice +19) and 'no priority boosting upwards' (nice -20) conditions. But > i like your patch, because it simplifies effective_prio() a bit, Yes and after some testing we should be able to drop the two BUG_ON() statements and simplify it even further. I only put them in because the original code meant that the implicit assertion: 0 <= CURRENT_BONUS(p) <= MAX_BONUS hasn't really been tested. As a result of code review, I'm pretty sure that it holds but it doesn't hurt to be careful. > and > with SCHED_BATCH we'll have the 'no boosting' property anyway. Could you > redo the patch against the current scheduler queue in -mm, so that we > can try it out in -mm? Attached is a patch against 2.6.15-rc5-mm3. > > Btw., another user-visible effect is that task_prio() will return the > new range, which will be visible in e.g. 'top'. I dont think it will be > confusing though. No, people will get used to it. Interactive tasks (with nice 0) now tend to get a dynamic priority of 20 instead of 15 which looks more natural (to me). But I guess it makes the interactive adjustment look more like a penalty imposed on non interactive tasks rather than a bonus given to interactive tasks. But this is simpler than the original version where it looks like a combination of a bonus to interactive tasks and a penalty for non interactive tasks. Peter -- Peter Williams pwil3058@bigpond.net.au "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce