On Sun, Mar 08, 2009 at 05:15:50PM +0100, Reinhard Tartler wrote: > a...@drcomp.erfurt.thur.de (Adrian Knoth) writes:
> > On Sat, Mar 07, 2009 at 02:47:28PM -0800, Steve Langasek wrote: > >> ardour uses mlock() on its ring buffers to ensure they're available in > >> physical memory. What if in order to meet this requirement, the kernel > >> instead swaps out the process stack and has to page that back in? What if > >> it drops the pages for the program itself out of the disk cache, and has to > >> read /that/ back from disk? > > I won't discuss this. The kernel RT wiki is very clear on that point, > > and all the audio developers do it for years. > > http://rt.wiki.kernel.org/index.php/HOWTO:_Build_an_RT-application#Latencies_caused_by_Page-faults > This article does not discuss Steve's arguments at all. While it is > moderatly well written, I think that especially the part about page > faulting needs more thought for general purpose systems like Debian. Well, the article is right that using mlockall() will have the desired effect wrt page faulting. It's just that: - ardour, the example given, doesn't *use* mlockall(), and using just mlock() doesn't give you any latency benefits at all. - if you really have a 970MB sample file that you need locked in memory, that plus the program plus stack+heap means you need > 1GB physical memory just to run this one application. I suppose these days it's straightforward to get a machine with 4GB of RAM or more, but for most people a memory requirement like this still means you're going to run the app on dedicated hardware; so if there's no resource contention, then mlockall() is redundant. (but permitting mlockall to work is simpler than uninstalling all the other packages that /could/ cause contention, via cronjobs etc.) > >>> > Increasming the mlock limit is a must and number one recommendation all > >> > over the net for pro-audio. jackd won't even start with realtime > >> > priority with the kernel's 32k limit. > >> Then that's a bug in the jackd package. > > Ok, it starts, but it won't have RT prio. And without RT prio, it's > > mostly pointless (especially in case of firewire audio interfaces > > handled by FFADO, resulting in many underruns and therefore crackle) > Perhaps we can do something with filesystem capabilities? Or perhaps > even some suid wrapper that drops priviledges immediatly after setting > the right priority? I cannot imagine that this hasn't been discussed yet > upstream. Could you (or anyone) provide pointers here? At least wrt setting the rtprio, I'm much more comfortable with having a config file added to /etc/security/limits.d than seeing more suid root wrappers added to the system. That doesn't solve the mlockall() question, though; but any solution that lets the audio user lock all the physical RAM is going to be a problem for the general case. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
