site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com - -- Terry _______________________________________________ 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... On Mar 14, 2007, at 2:16 AM, Quinn wrote: At 21:27 -0700 13/3/07, Michael Smith wrote: It's largely superseded by the (more standard) madvise(2). Which, last time I checked, was largely ignored by the kernel. In the currently released version of the OS, vm_map_behavior_set(), the underlying Mach API that implements it, defaults VM_BEHAVIOR_WILLNEED and VM_BEHAVIOR_DONTNEED, but it respects (by putting it in the object) VM_BEHAVIOR_DEFAULT, VM_BEHAVIOR_RANDOM, VM_BEHAVIOR_SEQUENTIAL, and VM_BEHAVIOR_RSEQNTL. Both vm_fault_is_sequential() and vm_fault_deactivate_behind() respect these flags. In particular, pages will be preemptively deactived for sequential reads of long enough runs, so mmap()'ing the data and setting MADV_SEQUENTIAL will likely get the behaviour he wants, as llong as his access is actually sequential. As far as "the pause button", there's a (normally privileged) call "malock() which could be used to lock the code path for the pause button into code (assuming you knew your front-end application well enough to know what pages were contained in that code path). If you did that, the reaction tme of the pause button would be more or less immediate. Alternately, setting the task priority to RT (it _is_ an AV application, after all) would give the paging in of the pause path priority, and, again, you'd get a more or less immediate response. As far as tuning the system, it's very hard to provide the knobs; despite the surface similarities, Tru64 and MacOS X are very different internally, and, for example, "ubc" MacOS X is about as really similar under the covers as "ubc" in NetBSD as it is to "ubc" in Tru64. Not only that, the traditional UNIX model for tuning ("turn off all limits, run it until it crashes with a particular workload, tune down the limits where it jumped the shark") doesn't tend to work very well for the customer. This email sent to site_archiver@lists.apple.com