On Tuesday 18 November 2003 02.41, Jack O'Quin wrote: > Fernando Pablo Lopez-Lezcano <[EMAIL PROTECTED]> writes: > > > - Can not provide mlockall since it has no pid parameter - the > > > monitor can't do it for another process. (I would say that it is > > > unlikely that pages used in a tight audio loop would be thrown out > > > - big buffers might... Add additional page reads?) > > > > Well, I'd say this is the showstopper. We really need this. "Unlikely" > > is not enough. Eventually memory will run out and the wrong page will > > fault and we get a click. We have to be able to lock memory...... > > Agreed. IMHO, mlock() is mandatory, certainly for JACK applications.
Problem is - why doesn't most distributions even ship with wrappers suid to be able to start the application with SCHED_FIFO/RT/mlock? - It is due to risks of local Denial Of Service attacks (intentional or unintentional) So with any scheme that opens up these holes you have to deliver a way to protect from the downsides. My monitor protects from CPU overuse, but what about memory? How to protect from an application that mlockall(MCL_FUTURE) and has a memory leak? One important thing to remember - if you like to get broad acceptance you have to suggest a solution that solves these problems. I would say that the rt_monitor or some other means to do the same thing is mandatory to get that kind of acceptance. > > The big difference between realtime and most other kinds of > performance work is that it focuses on tuning the "worst case", not > the average. Paging works fine on average, but in the worst case your > recording session gets blown. SCHED_FIFO does not make ANY guarantees on "worst case"! > > Otherwise, a good solution. Perhaps adequate for some applications. But at the same time SCHED_FIFO is adequate for most applications. See my point? :-) /RogerL -- Roger Larsson Skellefteċ Sweden