site_archiver@lists.apple.com Delivered-To: Darwin-dev@lists.apple.com On May 4, 2005, at 2:04 PM, Godfrey van der Linden wrote: _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... Yup this is basically the solution I was going to suggest. Keep a small pool of 'wired' memory around on the end of your I/O train. I'm afraid I'm not quite sure what the correct userland APIs are but I believe you are on the right track. You probably don't want to mlockall() in any case, but I'll guess p1003 is probably Posix 1003 spec (just a guess). I know that paging can be an issue, especially with audio, but an audio stream should be so hot that paging doesn't really occur. Have you been able to work out what pages are missing and why they are so cold? Perhaps a more complete analysis of page utilisation will reward you better then mlocking a bunch of pages? I wrote a paged-buffer class with selectable features such as wired, virtual-ring, shared, etc. During starting of an audio device, I first wire down and touch each page of the I/O ring buffers; when the device stops, they are unwired and/or freed. Any buffers that my audio/DSP and MIDI time-constrain threads utilize, I wire when in use. There are a few MacFOH users who only have 128 to 384 MB of RAM installed, and nobody has reported any thrashing issues. -- Shaun Wexler MacFOH http://www.macfoh.com This email sent to site_archiver@lists.apple.com