site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On Oct 10, 2006, at 10:34 AM, Alison Cassidy <cooties@mac.com> wrote: Does anyone know if there is a programmatic way of switching VM on and off, similar to the way Linux does it? I've good reason to do this (honest!) and need some way to disable VM for the duration of running my app or at the least, ensure it doesn't flush to disk at the wrong moment. Alison, = Mike _______________________________________________ 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... Let me start by asking the usual question: what is it that you are actually trying to achieve? While we wait for an answer, let's dissect what you asked above as an educational exercise. One does not "switch VM on and off" in Mac OS X or Linux. Virtualisation of the process address space is fundamental behaviour (modulo the no-MMU 'Linux' variants) of both systems; to "switch it off" can be considered impossible. You mention "swapon/swapoff", as though you assume that these tools do this. They do not. In the case of Linux, the operator can manually add and remove disk resources used for backing anonymous memory. Under Mac OS X this process is automatic and invisible to the user. By removing all of these resources, assuming that the system has enough physical memory, you would prevent paging out dirty pages when you need free pages. In this situation you haven't done anything about the need for free pages, so you will cannibalise pages in the system that are not backed by swap; that means program and library text/data pages, and pages mapped from files. For the most part this is a degenerate mode of operation; your pool of free-able pages is small and resident text pages tend to be part of your working set, so if you steal them for some other use some other page will shortly be stolen to back this text again, resulting in another I/O to refill it. This manifests as thrashing, because by making it impossible to clean dirty pages even after they are no longer part of the working set you have effectively reduced the amount of usable physical memory in the system. This can be mitigated to a degree by disabling overcommit (agan, not something that Mac OS X supports), and requiring that all allocations are fully backed by physical pages. You will find that no modern desktop environment will function in this mode. To address the spirit of your request; far too often we hear from developers an argument along the lines of "my app wants total control of the system". Well, sorry, you can't have it. You don't own the system, you cannot own the system, and you never will own the system. 8) It is up to you as a developer to work out how to get your job done while being a responsible partner in the operation of the system as a whole. There are other components that have real, necessary work to do, and you cannot necessarily expect them to either a) know that you are being selfish, or b) care. And you certainly can't expect them to be happy when c) you try to steal away from them the resources that they need and expect. That being said, there are ways to both express your needs, and to meet reasonable realtime targets without the sort of drastic measures that you allude to in your request. If we understand what you're trying to do a little better, it's possible that we can guide you in a useful direction, or at least explain what real constraints you're coming up against. This email sent to site_archiver@lists.apple.com