[linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24

[Roger Larsson]

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)
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