Messages in this thread | | | From | Con Kolivas <> | Subject | Re: Interactivity improvements | Date | Thu, 7 Aug 2003 07:15:29 +1000 |
| |
On Thu, 7 Aug 2003 04:48, Timothy Miller wrote: > Here's a kooky idea... > > I'm not sure about this detail, but I would guess that the int > schedulers are trying to determine relatively stable priority values for > processes. A process does not instantly come to its correct priority > level, because it gets there based on accumulation of behavioral patterns. > > Well, it occurs to me that we could benefit from situations where > priority changes are underdamped. The results would sometimes be an > oscillation in priority levels. In the short term, a given process may > be given different amounts of CPU time when it is run, although in the > long term, it should average out. > > At the same time, certain tasks can only be judged correctly over the > long term, like X, for example. Its long-term behavior is interactive, > but now and then, it will become a CPU hog, and we want to LET it. > > The idea I'm proposing, however poorly formed, is that if we allow some > "excessive" oscillation early on in the life of a process, we may be > able to more quickly get processes to NEAR its correct priority, OR get > its CPU time over the course of three times being run for the > underdamped case to be about the same as it would be if we knew in > advance what the priority should be. But in the underdamped case, the > priority would continue to oscillate up and down around the correct > level, because we are intentionally overshooting the mark each time we > adjust priority. > > This may not be related, but something that pops into my mind is a > numerical method called Newton's Method. It's a way to solve for roots > of an equation, and it involved derivatives, and I don't quite remember > how it works. But in any event, the results are less accurate than, > say, bisection, but you get to the answer MUCH more quickly.
Good thinking, but this is more or less already done in my code. I do have very rapid elevation of priority, and once something is known interactive it decays more slowly. It still _must_ be able to vary after the fact as interactive tasks can turn into cpu hogs and so on.
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/
| |