Re: [patch] SCHED_SOFTRR starve-free linux scheduling policy ...

[Pavel Machek <pavel@suse.cz>]

Hi!

> >> >> 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.
> >>
> >> Everything I've seen says "you need at least a 300Mhz cpu to decode".  My
> >> little cpu is 500Mhz, so I'd have to make more than half of my total
> >> computational power available for SCHED_SOFTRR tasks for video decode in
> >> realtime to work.  Even on my single user box, I wouldn't want to have to
> >> fight for cpu because some random developer decided to use
> >> SCHED_SOFTRR.  If I make that much cpu available, someone will try to use
> >> it.  Personally, I think you should need authorization for even tiny
> >> amounts of cpu at this priority.
> >
> >What about only offering SCHED_SOFTRR to people logged in on console,
> >similar to way cdrom and /dev/dsp is handled on newer boxes?
> 
> I'm always logged in on console, so with no authorization required, it'd 
> always be available to every task I start.

Which is pretty much okay. Remember that UID (not PID) is security
barier. If one of your processes is able to do X, all other processes
running under your PID are able to do X, too. (Modulo processes with
few differend PIDs, its more complicated then.)

								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]