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

From: Con Kolivas
Date: Sat May 29 2004 - 06:20:46 EST


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/