Hi!
> On 25 Feb 2000, Dimitris Michailidis 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.
Unfortunately, that clever trick is not present in this sched patch.
Pavel
-- I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents me at discuss@linmodems.org- 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:20 EST