Subject: Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24
From: Fernando Pablo Lopez-Lezcano (nando_AT_ccrma.stanford.edu)
Date: Tue Nov 18 2003 - 21:47:43 EET
On Mon, 2003-11-17 at 23:22, Roger Larsson wrote:
> On Tuesday 18 November 2003 02.41, Jack O'Quin wrote:
> > Fernando Pablo Lopez-Lezcano <nando_AT_ccrma.stanford.edu> 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)
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 :-)
> 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"!
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).
> > Otherwise, a good solution. Perhaps adequate for some applications.
>
> But at the same time SCHED_FIFO is adequate for most applications.
> See my point? :-)
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
This archive was generated by hypermail 2b28 : Tue Nov 18 2003 - 21:46:15 EET