Messages in this thread | | | Date | Wed, 21 Dec 2005 10:36:29 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH] cpu scheduler: unsquish dynamic priorities |
| |
* Peter Williams <pwil3058@bigpond.net.au> 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, 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?
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.
Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |