On Fri, 05.06.09 11:11, Jon Masters (jonathan@xxxxxxxxxxxxxx) wrote: > > > Anyone want to clarify my understanding of PA's use of > > > mlock/posix_madvise? From looking over the code - in particular > > > pa_will_need, and its callsites - it looks like PA doesn't really use > > > this support that it has for locking pages. Which seems weird. > > > > mlock() is not actually used anymore by PA on modern kernels. > > I noticed :) But then, neither is the posix_madvise being used that much > either, as I noted. Yes, that is true. We primarily use that when playing samples from the cache, since the sample cache has a very high and obvious probability to be swapped out. We probably should place these calls at other strategic points. > > Text book RT applications use mlock()/mlockall() to lock themselves > > into memory and make sure they never are swapped out. This is > > something we cannot really do for PA given that map a *lot* of stuff > > into our address space: libraries, SHM segments for communications > > with other clients, cached samples, and so on. If we'd lock all that > > into memory there wouldn't be any memory left for much else > > Yeah, I'm aware of this. But there perhaps should be some option anyway > - after all, you already have all the support code for it, and already > handle setting real time priorities too. In my brief time with a hacked > up local build that does an mlockall right at the beginning of the > mainloop, I am hearing few audio pops and skips on this box. It's > obviously not a longer term solution, just a datapoint. Hmm, interesting. You really say mlockall() has a big effect? An option to use mlockall certainly does make sense. I have added that now to PA git in commit a9b38b35. > It did drastically reduce it. The box is under extremely heavy stress as > it's running a lot of stuff - dozens of firefox, many evolution windows, > IRC, rhythmbox, a few VMs, etc. I'm looking forward to the IO Controller > patches so I can e.g. prevent evolution from hogging more than a certain > amount of disk bandwidth, which I'm sure will help. What would be good to have would be a "swap niceness" value that could be attached to a processes or memory regions. i.e. some way to influence the swapping algorithm in a less binary way than just "swap this" or "don't swap this". > > I doubt that locking PA into memory will fix your issues. If PA drops > > out often this might have various reasons, but probably not > > swapping. Often the timing calls of your sound driver are inaccurate > > and cause PA to miss its deadlines. > > The Intel HDA driver on here doesn't appear to be in your badlist any > more, but maybe I am wrong: > > 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High > Definition Audio Controller (rev 02) The actualy codec used is more interesting. The codec is shown at the top of the 'alsamixer' screen. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
