On Sat, 6 Oct 2001, george anzinger wrote:
> Alan Cox wrote:
> > So if you used your cpu quota you will get run reluctantly. If you slept
> > you will get run early and as you use time slice count you will drop
> > priority bands, but without pre-emption until you cross a band and there
> > is another task with higher priority.
> >
> > This damps down task thrashing a bit, and for the cpu hogs it gets the
> > desired behaviour - which is that the all run their full quantum in the
> > background one after another instead of thrashing back and forth
>
> If I understand this, you are decreasing the priority of a task that is
> running as it consumes its slice. In the current way of doing things
> this happens and is noticed when the scheduler gets called. A task can
> loose its place by being preempted by some quick I/O bound task. I.e. A
> and B are cpu hogs with A having the cpu, if task Z comes along and runs
> for 100 micro seconds, A finds itself replace by B, where as if Z does
> not come along, A will complete its slice. It seems to me that A should
> be first in line after Z and not bumped just because it has used some of
> its slice. This would argue for priority being set at slice renewal
> time and left alone until the task blocks or completes its slice.
It certainly argues for continuing to run the process with the unexpired
timeslice, becausle it is most likely to have current data in caches of
every type.
-- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.- 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/
This archive was generated by hypermail 2b29 : Sun Oct 07 2001 - 21:00:43 EST