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/
This archive was generated by hypermail 2b29 : Thu Aug 07 2003 - 22:00:35 EST