[lkml]   [2003]   [Aug]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] SCHED_SOFTRR starve-free linux scheduling policy ...
On Saturday 09 August 2003 19.47, Mike Galbraith wrote:
> 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 :
> > >
> > >
> >
> > "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.

I would prefere to have it as a sub range "min real RT" <SOFT_RR range < mean
real RT. Using SOFTRR time slice that is inverse proportional with the level
might also be beneficial.

> 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.

Why shouldn't it be useful with video, is a frame processing burst longer than
a time slice? The rule for when to and how to revert a SCHED_SOFTRR can be

* SCHED_FIFO requests from non root should also be treated as SCHED_SOFTRR


Roger Larsson
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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