On Fri, 2009-06-05 at 12:57 +0200, Lennart Poettering wrote: > 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. I noticed :) But then, neither is the posix_madvise being used that much either, as I noted. On a related note, I have revived the upstream discussion of MCL_INHERIT and will repost patches implementing this over the weekend - then I can have a simple wrapper utility to test forcing an app like PA to do an mlockall. > 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. > There is a system call for requesting swapping in of memory: > posix_madvise(POSIX_MADV_WILLNEED). Yeah, I saw that and I think it's a nice idea. I'm not sure it's being called very often though - bear in mind I only spent a few minutes looking at the source, so I might have missed something. > > 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. 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. > 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) > 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. I will try that. > Then restart PA. Another issue might be that PA does not actually > get scheduled often enough by the kernel. I don't think it's that. There's no closed source driver installed. I also am currently running PA as an RT task and my SMI detector shows that this box is not disappearing off into SMI land too often. > Usually running "pulseaudio -vvvvv" in a terminal might give you a > hint what might be going wrong. Not very much useful output when I set it into a debug loglevel - maybe this is different. Jon. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
