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: [EMAIL PROTECTED]