On 11 Mar 2000, Dimitris Michailidis wrote:
> + /*
> + * Potentially available timeslices are retrieved
> + * here - this way the parent does not get penalized
> + * for creating too many processes.
> + *
> + current->counter += p->counter;
> + if (current->counter > current->priority)
> + current->counter = current->priority;
whoops, this should be:
if (current->counter > current->priority*2)
current->counter = current->priority*2;
(current->priority*2 is the maximum timeslice a process can win through
multiple recalculations)
The reason of the above fixes is to not punish processes for creating many
short-lived threads. There is nothing wrong about creating a new thread,
and the previous code 'drained' timeslices from the parent if it was
creating threads at a high rate. This was a RL performance problem for
certain application patterns. A longstanding problem.
> This tick reclamation looks questionable if the parent's counter has
> been renewed since the fork(). In that case, contrary to the comment,
> the above can be used to artificially 'generate' timeslices.
well the parent's counter is indifferent, i guess you mean the child's
counter? In that case it's true, but it's a 'slow' method and a different
timescale. We had two different (buggy) situations: prior 2.0.33 on fork()
we just duplicated the parent's timeslice, which made Linux an easy target
for fork bombs (and it also hurts interactive performance because it's
unfair against non-heavy-forking processes). After 2.0.33 [which small 2.0
change was from me so the blame is on me] we did an imperfect 'split' of
the parent's timeslice:
current->counter >>= 1;
p->counter = current->counter;
this caused 'leakage' of (rightfully obtained) parent timeslices when the
counter was uneven, and worse, on exit the exiting thread dropped
timeslices completely, which in turn starved the parent.
now there is no 'fast' method of winning/losing timeslices (the flux of
timeslices is balanced), which closes the hole both for forkbombs and
fixes heavily threaded workloads. Think of the timeslice transfer as a
'priority boost' to the parent: the parent will likely have some work to
do due to the child exiting. Even if it's imperfect if the child got a
recalculation meanwhile, it does make sense.
Ingo
-
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/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:22 EST