Pavel Machek wrote:
>
> > > * adds a new scheduling policy SCHED_IDLE. Processes of this type run on CPUs
> > > that would otherwise be idle. Useful for apps like SETI@Home, code crackers,
> > > etc. Implementation of this feature is extremely lightweight.
> > > Among the scheduling functions only schedule() is SCHED_IDLE-aware
> > > and the overhead for non-idle CPUs is at most 1 instruction per schedule()
> > > invocation;
> >
> > So why do you think your implementation of this doesn't have the deadlock
> > that every other implementation has?
> >
> > The deadlock is due to priority inversion, where a "idle-priority" task
> > gets a resource (say the directory semaphore), goes to sleep, and never
> > wakes up again because there is some slightly more important process
> > running all the time.
> >
> > In short, this has been tried before, and it has ALWAYS been a serious
> > security holw full of denial-of-service kind of attacks.
>
> No. Once upon a time, there was trick which enabled slow for
> SCHED_IDLE processes (by abusing flags -- something like PTRACE), then
> did priority boost in slow path. I even remember it made fast path
> slightly faster by assembly level optimalization.
if you're referring to my sched_idle hack, then it's still exists, but
never really made it past the proof of concept stage. [somebody else
was interested in maintaining it though]. Anyway, even w/o any special
handling, the deadlock is no worse than the SCHED_OTHER vs SCHED_{RR,FIFO}
one; it's just that it's more likely to get triggered in a typical setup.
I will probably be dropping the ptrace hack anyway, as it may prevent
some kernel entry optimizations. you should be able to work around the
deadlock by having a kernel thread periodically check the thread queue
and raise the idle threads priority temporarily. [you'll need a thread
anyway for reasonable signal handling] The current scheduler doesn't
really support many static priorities so that any sched_idle solution
will be a hack. [and this is good, a more complex scheduler would create
more problems than it would solve]
there are much more important issues than sched_idle, and these should
be fixed first.
-
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 : Tue Feb 29 2000 - 21:00:23 EST