Messages in this thread | | | Date | Tue, 14 Mar 2000 10:24:59 -0600 (CST) | From | Jeff Garzik <> | Subject | RE: 2.3.51: 'timeslice transfer' |
| |
On Mon, 13 Mar 2000, Dimitris Michailidis wrote:
> > 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/ >
- 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/
| |