OK, you're right about that one -- a slight brain fart on my
side. Then again, we probably want to make goodness() a bit
cheaper than it is now because we're calling it more often
than before....
> > [...] and the fact that the kernel still recalculates
> > the priority of _all_ processes as soon as one process runs
> > out of it's time slice.
>
> this recalculation argument is a complete red herring. I've explained this
> earlier too: the number of recalculations happens at a _constant
> frequency_, with the additional mechanizm that there are less
> recalculations if there are more CPU-bound processes. The goal is to have
> tasks' increase their 'dynamic priority' even if they are not on the
> runqueue. So any architectural change that concentrates on removing these
> recalculations is seriously misguided.
I've got a new scheme in mind which uses a new variable in
the task struct in order to make goodness simpler, increase
the range of CPU usage (for niced tasks), favor interactive
performance better and get rid of the recalculation as a
nice side effect...
Btw, the rate of recalculation increases with more CPUs in
the machine so I wouldn't be surprised if it didn't scale
well to number crunching machines with a lot of nice +19
tasks.
Anyway, I think I can bring my point across much better in
C than in english, so I'll focus on some source code now...
cheers,
Rik -- Open Source: you deserve to be in control of your data.
+-------------------------------------------------------------------+
| Le Reseau netwerksystemen BV: http://www.reseau.nl/ |
| Linux Memory Management site: http://humbolt.geo.uu.nl/Linux-MM/ |
| Nederlandse Linux documentatie: http://www.nl.linux.org/ |
+-------------------------------------------------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/