Messages in this thread | | | Date | Mon, 13 Mar 2000 11:17:31 -0800 (PST) | From | Dimitris Michailidis <> | Subject | RE: 2.3.51: 'timeslice transfer' |
| |
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/
| |