lkml.org 
[lkml]   [2000]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.115 / U:0.372 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site