On 12-Mar-2000 Ingo Molnar wrote:
> 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)
2 * current->priority - 1 really. The following is more correct:
if (current->counter >= current->priority*2)
current->counter = current->priority*2-1;
> 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.
The exploitation I had in mind is this. Have a process almost exhaust its
slice, say take its counter down to 2. Then fork() and let both parent and
child go through a recalculation. Now the child exits transfering its slice
to the parent. The parent ends up with a maxed out counter and a slice that
is twice as long as it could have gotten otherwise (and high priority in
the eyes of goodness()). If it wants an even longer timeslice it can fork()
more than one child and have them exit at appropriate times. A process can
get a steady supply of free ticks this way. Of course its slice will reach
0 at some point but it can start all over again after the next
recalculation. The only tricky part is getting the timing right.
-- Dimitris Michailidis dimitris@engr.sgi.com- 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:26 EST