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

[Peter Williams]

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.

Peter
--
Dr Peter Williams                                pwil3058@xxxxxxxxxxxxxx

"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce

-
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/