Messages in this thread | | | Date | Sun, 27 Feb 2000 22:08:38 +0100 | From | Pavel Machek <> | Subject | Re: [PATCH] proposed scheduler enhancements and fixes |
| |
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/
| |