18 Nov
2003
18 Nov
'03
3:48 p.m.
On Mon, 2003-11-17 at 23:22, Roger Larsson wrote:
Correct. We do have xruns every once in a while, it depends a lot on the
hardware and how the system is tuned. If we get real serious, from the
point of view of "worst case", linux is the wrong tool to do realtime
audio processing. Something like QNX would be better (a _real_ realtime
operating system).
I see your point. There is no clearly marked dividing line in either
case. For a certain very high latency requirement SCHED_OTHER, in the
average, is just fine. For the latency expectations of most people in
this list SCHED_FIFO is a good solution (if the kernel is patched for
low latency operation - otherwise it does not work either). If you
really go down in latency, SCHED_FIFO is no longer good enough. This
part at least is clear to me (we _need_ SCHED_FIFO), but equally clear
is the fact that it will not _always_ work (100% of the time).
So the question about mlockall would be, is it something akin to
SCHED_OTHER? (ie: with it the whole thing is unusable?). Or is it like
SCHED_FIFO? (ie: not 100% perfect but we really need to have it?).
My feeling is that we need it, but I don't have experimental data to
back it up.
Any one out there doing experiments with this? Something like: start a
critical audio app with and without mlockall, subject the machine to
high memory loads to force paging (ie: start a lot of applications), see
what happens.
Of course there does not have to be just _one_ answer to the question!
Let's implement both and let the user choose according to his/her/its
needs :-)
-- Fernando
On Tuesday 18 November 2003 02.41, Jack O'Quin
wrote:
That's one reason why you won't see this done on any general purpose
distribution. Another reason: most (all?) mainstream distributions do
not cater to the "pro audio" users that need very reliable and very low
latency operation. Yet another: it is difficult :-)
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) - 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...... So with any scheme that opens up these holes you have
to deliver a way
to protect from the downsides.
Or not. Sometimes you have to learn to live with them...
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?
Good point. Probably you can't.... :-(
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.
I don't (personally) want or need at this point in time for the solution
to have "broad acceptance", although that would be real nice. I want
something that enables me to run applications with real time priority
and memory lock as a normal user. So far the options that target both
aspects (scheduler and memory lockdown) involve a kernel patch.
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? :-)