site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On May 31, 2008, at 4:11 AM, Tim Seufert wrote: = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... Along those lines... do you ever do anything like transcode video, or use any other software which reads large files? Many free video encode/transcode programs let the OS cache their input files even though they're reading the data exactly once. Such programs can put enormous dynamic pressure on the VM. Whenever some other process adds a bit of pressure of its own, swap storms are likely. Such software was a pretty reliable way to bring 10.4 (or earlier) to its knees. I haven't tried it under 10.5, and my understanding is that Leopard's buffer cache has been upgraded to better handle read-once I/O patterns, but it could still be an issue. The issue here (regarding large file I/O) is a difficult tradeoff in the VM/buffer cache that Darwin makes differently from some other systems. Under Darwin, applications are expected to advise the OS when they write file data that won't be re-used rapidly; a failure to do this will cause the system to dedicate cache pages to recently-written file data in preference to less-recently used application text and data, which then has to be paged back in. This choice has real performance benefits in other scenarios, but it does fall down when applications move large amounts of file data rapidly without telling the system that it's not useful to cache it. You're welcome to play armchair architects over the choice of policy, but bear in mind that it was made (and is regularly being remade) consciously and with reasons that make good sense to the folks making the decisions. This email sent to site_archiver@lists.apple.com