site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Indeed! :) Thanks again, -- Allie _______________________________________________ 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... On Oct 10, 2006, at 10:51 AM, Justin C. Walker wrote: On Oct 10, 2006, at 10:34 , Alison Cassidy wrote: Fair point. However, I'm assuming the kernel memory management will deal accordingly in some sane manner. See; http:// unixhelp.ed.ac.uk/CGI/man-cgi?swapoff+2 Mac OS X is not Linux :-} In any case, from that man page, I don't see how you can do both of "quiet all disk activity" and avoid the problem I mention above (which really isn't specific to your process; modern OSs have a lot of processes that can fire at any time to handle the exigencies of the moment; they need to be able to run, or the system crumbles). Right. I'll never quiet *all* disk activity; all I can hope for is to minimize it somehow. You could, as mentioned earlier in this thread, avoid enabling the paging daemon. With sufficient memory, you could run a full system, but things may start failing in strange ways without the elasticity provided by a backing store. In case you haven't looked in depth at the Mac OS X VM system, it's all handled by the paging daemon. There is no path to disk (for this purpose) within the kernel. Right (and thanks John and Graham for the info there). I'd considered messing about with dynamic_pager but wouldn't like to modify the boot args nor kill it outright for very obvious reasons. I need to look into the workings of the paging daemon some more ... This email sent to site_archiver@lists.apple.com