Messages in this thread | | | Date | Tue, 19 Aug 2003 13:06:49 +1000 | From | Nick Piggin <> | Subject | Re: scheduler interactivity: timeslice calculation seem wrong |
| |
Eric St-Laurent wrote:
>currently, nicer tasks (nice value toward -20) get larger timeslices, >and less nice tasks (nice value toward 19) get small timeslices. >
Funny, isn't it!
> >this is contrary to all process scheduling theory i've read, and also >contrary to my intuition. >
Yep.
> >maybe it was done this way for fairness reasons, but that's another >story... > >high priority (interactive) tasks should get small timeslices for best >interactive feeling, and low priority (cpu hog) tasks should get large >timeslices for best efficiency, anyway they can be preempted by higher >priority tasks if needed. >
Its done this way because this is really how the priorities are enforced. With some complicated exceptions, every task will be allowed to complete 1 timeslice before any task completes 2 (assuming they don't block).
So higher priority tasks need bigger timeslices.
> >also, i think dynamic priority should be used for timeslice calculation >instead of static priority. the reason is, if a low priority task get a >priority boost (to prevent starvation, for example) it should use the >small timeslice corresponding to it's new priority level, instead of >using it's original large timeslice that can ruin the interactive feel. >
Among other things, yes, I think this is a good idea too. I'll be addressing both these issues in my scheduler fork.
I do have dynamic timeslices, but currently high priority tasks still get big timeslices.
- 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/
| |