Messages in this thread | | | From | Roger Larsson <> | Subject | Re: [patch] SCHED_SOFTRR starve-free linux scheduling policy ... | Date | Sun, 10 Aug 2003 04:05:52 +0200 |
| |
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 : > > > > > > 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. >
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 changed.
* SCHED_FIFO requests from non root should also be treated as SCHED_SOFTRR
/Rogerl
-- Roger Larsson Skellefteå Sweden - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |