Peter Williams wrote: > 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. On the assumption that you're still interested in trying this patch out I've attached a version against 2.6.15-mm1. > >> >> 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. > Signed-off-by: Peter Williams -- Peter Williams pwil3058@bigpond.net.au "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce