On Mon, 13 Mar 2000, Dimitris Michailidis wrote:
> 2 * current->priority - 1 really. The following is more correct:
>
> if (current->counter >= current->priority*2)
> current->counter = current->priority*2-1;
nod.
> > 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.
yep, this is possible, but i dont think it's anything new. It's already
(and was always) possible (and more generic) to do this with the following
method (with any scheduler): create 10 CLONE_PID threads which
'roundrobin' execute the same code, with a very simple user-space
scheduler executed out of a SIGALARM signal handler. Only one thread is
executing at a time. A thread executes only for 2 timeslices (alarm clock
set to 1), and switches over to another thread to continue with the same
register set. 9 threads will be 'candidates for recalculation', and
timeslices are 'pumped' into the COE. No special timing necessery, and
'success' is guaranteed.
you can abuse any but the most anal schedulers if you are allowed to run
multiple processes/threads. On systems where this could be a problem
strict resource (process) limits and CPU time accounting and monitoring
should be used.
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:26 EST