Re: [patch] SCHED_SOFTRR starve-free linux scheduling policy ...
From: Mike Galbraith
Date: Sat Aug 09 2003 - 12:47:57 EST
At 03:05 PM 8/9/2003 +0100, Daniel Phillips wrote:
Hi Davide,
On Sunday 13 July 2003 22:51, Davide Libenzi wrote:
> This should (hopefully) avoid other tasks starvation exploits :
>
> http://www.xmailserver.org/linux-patches/softrr.html
"We will define a new scheduler policy SCHED_SOFTRR that will make the
target task to run with realtime priority while, at the same time, we will
enforce a bound for the CPU time the process itself will consume."
This needs to be a global bound, not per-task, otherwise realtime tasks can
starve the system, as others have noted.
But the patch has a much bigger problem: there is no way a SOFTRR task can be
realtime as long as higher priority non-realtime tasks can preempt it. The
new dynamic priority adjustment makes it certain that we will regularly see
normal tasks with priority elevated above so-called realtime tasks. Even
without dynamic priority adjustment, any higher priority system task can
unwttingly make a mockery of realtime schedules.
Not so. Dynamic priority adjustment will not put a SCHED_OTHER task above
SCHED_RR, SCHED_FIFO or SCHED_SOFTRR, so they won't preempt. Try
this. Make a SCHED_FIFO task loop, then try to change vt's. You won't
ever get there from here unless you have made 'events' a higher priority
realtime task than your SCHED_FIFO cpu hog. (not equal, must be higher
because SCHED_FIFO can't be requeued via timeslice expiration... since it
doesn't have one)
I do see ~problems with this idea though...
1. SCHED_SOFTRR tasks can disturb (root) SCHED_RR/SCHED_FIFO tasks as is.
SCHED_SOFTRR should probably be a separate band, above SCHED_OTHER, but
below realtime queues.
2. It's not useful for video (I see no difference between realtime
component of video vs audio), and if the cpu restriction were opened up
enough to become useful, you'd end up with ~pure SCHED_RR, which you can no
way allow Joe User access to. As a SCHED_LOWLATENCY, it seems like it
might be useful, but I wonder how useful.
-Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/