On Fri, 05.06.09 00:21, Jon Masters (jonathan@xxxxxxxxxxxxxx) wrote: > Folks, > > 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. The longer story goes like this: 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, i.e. all other programs would have to share what is remaining and would have to swap all the time. Given that PA is just an auxiliary tool and not the main reason people run computers this is hence not an option. Due to that PA doesn't use mlock()/mlockall() like textbooks suggest, and it never did. Now, just ignoring the whole locking issue is also not an option. So I tried to find a compromise: try my best to make sure that the data accessed by the RT threads is available in memory but ignore the rest of the memory. To achieve that I needed a way to safely swap in memory when *I* need it to instead of letting the kernel to do as it as late as possible. Then, whenever the non-RT threads in PA pass off data to the RT threads I first swap the data in explicitly. That way I hope that the RT threads never need to wait for swapping in and can continue to loop in their little loops and continue to do whatever else they might want to do, but not wait for disks spinning. There is a system call for requesting swapping in of memory: posix_madvise(POSIX_MADV_WILLNEED). A few kernel releases ago this didn't work for anonymous memory, only for file-backed memory. (But on my request this was then changed in the kernel). Now, to support older kernels I added a dirty dirty hack: I try to lock those pages into memory and then unlock them right away, which should have about the same effect as the madvise() call. On current kernels that mlock() is never tried however, because WILLNEEED works fine anyway. And it's a horrible hack. And I probably should remove this from PA now. > I'll admit I'm about ready to hack in some horrible mlockall hacks to > see if that'll stop the poppy/skippyness on this box. 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. To work around that you could try disabling timer-based scheduling mode and revert to sound card IRQ scheduled playback. For that try passing "tsched=0" to module-hal-detect in /etc/pulse/default.pa. Then restart PA. Another issue might be that PA does not actually get scheduled often enough by the kernel. Might be caused by a bad driver (nvidia closed source). You can run PA as RT if you wish (which we hopfully will be able to enable by default in F12). For that increase RLIMIT_RTPRIO to 10 or so in /etc/security/limits.conf and login again. Usually running "pulseaudio -vvvvv" in a terminal might give you a hint what might be going wrong. 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
