[linux-audio-dev] new realtime scheduling policy

[rm]

On Tue, Mar 18, 2003 at 12:23:55PM -0500, Paul Davis wrote:
>
> i agree, but i also raise another angle that i spoke about a couple of
> times at zkm this last weekend.
> 
> using SCHED_(USER)?FIFO makes no sense if you do not also call
> mlockall(2). 

(for us...i can think of cases where this isn't true). 

> both (scheduling+memory pinning) are inaccessible without
> root or CAP_SYS_RESOURCE capabilities. i think that a very useful
> patch would be one that used /proc/sys/kernel/rtperm (or some similar
> [...]
> it would be a very simple patch, i believe, touching just 2
> non-hotspots in the kernel. 

no question it would be easy and non-invasive. we could again reserve
some amount of resources which the user couldn't pin to provide some
protection. 

the problem i see with it is that, for this to be useful, (ie, help
the people for which the capsys stuff is too much trouble), it has to
be in the kernel that comes with their distribution. but i really
don't see this getting into the mainline kernel...though perhaps media
friendly distros will put it in. 

so the short of it is: i can make a patch to the kernel and maintain
them (both the user sched_fifo limit and user mlock limit should need
very little to track current kernels (i can look into the changes
necessary for 2.5 kernels)), but the question is what do you then want
to see happen to the patches? i don't think they should be included in
the mainline kernel. 

i'm also going to look at how bsds handles this stuff.

		rob
----
Robert Melby
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp:     ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt4255a
Internet: async at cc.gatech.edu