Re: Darwin-dev Digest, Vol 3, Issue 264
Re: Darwin-dev Digest, Vol 3, Issue 264
- Subject: Re: Darwin-dev Digest, Vol 3, Issue 264
- From: Michael Smith <email@hidden>
- Date: Wed, 11 Oct 2006 00:35:12 -0700
On Oct 10, 2006, at 10:34 AM, Alison Cassidy <email@hidden> 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,
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.
= Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden