Messages in this thread | | | From | Con Kolivas <> | Subject | Re: [RFC][PATCH][2.6.6] Replacing CPU scheduler active and expired with a single array | Date | Sat, 29 May 2004 21:17:55 +1000 |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |