18 Nov
2003
18 Nov
'03
3:22 a.m.
On Tuesday 18 November 2003 02.41, Jack O'Quin wrote:
Fernando Pablo Lopez-Lezcano
<nando(a)ccrma.stanford.edu> writes:
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.
- 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......
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