Re: [RFC][PATCH][2.6.6] Replacing CPU scheduler active and expired with a single array

[Con Kolivas]

On Sat, 29 May 2004 15:27, Peter Williams wrote:
> Con Kolivas wrote:
>  > On Fri, 28 May 2004 19:24, Peter Williams wrote:
>  > > Ingo Molnar wrote:
>  > > > just try it - run a task that runs 95% of the time and sleeps 5%
>  > > > of the time, and run a (same prio) task that runs 100% of the
>  > > > time. With the current scheduler the slightly-sleeping task gets
>  > > > 45% of the CPU, the looping one gets 55% of the CPU. With your
>  > > > patch the slightly-sleeping process can easily monopolize 90% of
>  > > > the CPU!
>  > >
>  > > This does, of course, not take into account the interactive bonus.
>  > > If the task doing the shorter CPU bursts manages to earn a larger
>  > > interactivity bonus than the other then it will get more CPU but
>  > > isn't that the intention of the interactivity bonus?
>  >
>  > No. Ideally the interactivity bonus should decide what goes first
>  > every time to decrease the latency of interactive tasks, but the cpu
>  > percentage should remain close to the same for equal "nice" tasks.
>
> There are at least two possible ways of viewing "nice": one of these is
> that it is an indicator of the tasks entitlement to CPU resource (which
> is more or less the view you describe) and another that it is an
> indicator of the task's priority with respect to access to CPU resources.
>
> If you wish the system to take the first of these views then the
> appropriate solution to the scheduling problem is to use an entitlement
> based scheduler such as EBS (see
> <http://sourceforge.net/projects/ebs-linux/>) which is also much simpler
> than the current O(1) scheduler and has the advantage that it gives
> pretty good interactive responsiveness without treating interactive
> tasks specially (although some modification in this regard may be
> desirable if very high loads are going to be encountered).
>
> If you want the second of these then this proposed modification is a
> simple way of getting it (with the added proviso that starvation be
> avoided).
>
> Of course, there can be other scheduling aims such as maximising
> throughput where different scheduler paradigms need to be used.  As a
> matter of interest these tend to have not very good interactive response.
>
> If the system is an interactive system then all of these models (or at
> least two of them) need to be modified to "break the rules" as far as
> interactive tasks are concerned and give them higher priority in order
> not to try human patience.
>
>  > Interactive tasks need low scheduling latency and short bursts of high
>  > cpu usage; not more cpu usage overall. When the cpu percentage
>
> differs > significantly from this the logic has failed.
>
> The only way this will happen is if the interactive bonus mechanism
> misidentifies a CPU bound task as an interactive task and gives it a
> large bonus.  This seems to be the case as tasks with a 95% CPU demand
> rate are being given a bonus of 9 (out of 10 possible) points.

This is all a matter of semantics and I have no argument with it.

I think your aims of simplifying the scheduler are admirable but I hope you 
don't suffer the quagmire that is manipulating the interactivity stuff. 
Changing one value and saying it has no apparent effect is almost certainly 
wrong; surely it was put there for a reason - or rather I put it there for a 
reason.

Con
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/