Re: RAM Cache vs the Pageout Demon
Re: RAM Cache vs the Pageout Demon
- Subject: Re: RAM Cache vs the Pageout Demon
- From: Michael Smith <email@hidden>
- Date: Tue, 24 Oct 2006 03:12:31 -0700
On Oct 23, 2006, at 12:11 PM, Russ wrote:
--- Michael Smith <email@hidden> wrote:
I think OS X's preemptive pageout to maintain minimum free list (see
http://developer.apple.com/documentation/Performance/Conceptual/
ManagingMemory/Articles/AboutMemory.html)
is counterproductive, vs waiting for actual free-space demand.
You do, eh? Well, let's assume just for the moment that the kernel
needs those free pages in order to make forward progress when an
application like yours thinks it needs every last page in the system.
Untouched pages can be reclaimed at any time by the operating
system without
penalty. Doing so before necessary causes an avoidable performance
loss.
I'm not sure what your statement here is in reply to, but since it's
wrong, I might as well attempt to clarify and correct the points you
seem to be trying to make. 8)
An 'untouched' page is a virtual allocation with no physical backing
page. I have to assume that what you mean is a clean page (i.e. one
that has been touched but whose contents have not been written to).
Sadly, there are several costs associated with obtaining clean pages;
locking overheads, finding a clean page in the first place, zero
filling it - all of these things refute your "without penalty"
assertion.
It is also not practical or fair to only steal clean pages when you
are trying to find a free page; clean pages typically hold important
things like program text, filesystem metadata buffers and read-only
mapped file data, and evicting these in favour of cleaning less
recently-referenced dirty pages can in the case of an application
like yours lead to premature code thrashing; code thrash is
particularly pernicious because it tends to have poor locality of
reference and thus very poor page-in efficiency (clustered pageins
notwithstanding).
All of this leads to the point that I was trying to convey, which is
that the operating system has a good idea about how many free pages
it has to hold in reserve in order to satisfy the peak requirements
of both realtime code and the pageout path in the case where it must
clean pages before returning them to the freelist.
Mac OS X does not pre-emptively clean and free pages in the fashion
that FreeBSD etc. do; it maintains a very small pool of free pages
(no more than a few percent of the physical memory present in the
system).
If people are running my app on a 2 GB machine, try telling them
they can only
cache 1 GB because there are 50 background processes they've never
heard of
that need RAM too. If people buy a 2 GB machine, they expect to be
able to use
most of it, regardless of the details.
That's terribly pugnacious. I would, however, assert that if their
2GB machine performs like a pig because your application is making
poor use of all that RAM, perhaps they have a right to be upset about
that too? 8)
you can more realistically assess the amount of
free memory required to display an image before bringing it into your
cache, and thus whether the sum of cached images poses a threat to
your working set.
I already have code that can reduce RAM cache if memory gets low.
Can you
suggest a precise predictive criteria for doing this? If the RAM
cache is
reduced programatically, the user can see what's happening and the
machine
stays interactive. If it starts thrashing, UI response goes down
the tubes.
"Can you teach me how to tell the future"? Obviously, not. But you
can make some intelligent guesses about memory pressure based on
deviations from your expected response times and shrink your working
set to compensate.
If you have full control over the environment in which your
application runs, then you have a better opportunity to size it
accordingly. If you don't, then your entire assertion that the
machine belongs to you is invalid, and you need to start thinking
about how to make your application a good citizen rather than a
resource hog.
In the common case, you have no control over what the system's
footprint is going to look like on a moment to moment basis; you can
see how this is inevitable as soon as you imagine another application
with the same expectations running side-by-side with yours.
I could probably find out the minimum and current free list sizes,
but that is
unduly conservative if more memory can be wrung out of other
processes.
You completely fail to understand the nature of the system here.
Physical memory is allotted on an as-needed basis. If another app
has physical pages it's because that application needs them; it has
run in order to perform necessary work, and that work necessarily
touches memory. You don't "wring memory out of other processes". If
they need it, they get it. If you need it, you get it.
Even if OS X wants to grab some pages to maintain
its free list, I need it to grab them from inactive processes, not
the ones it
thinks are inactive in my app.
If those tasks are truly more inactive than you, you will already
have stolen all the pages from them that you can.
Part of the problem is that if you are playing through 10 or 20
seconds of
imagery, you don't get around to it very often, but when you do,
you still want
it there.
If that's the case, then you need to ensure that the system's working
set plus the total footprint of those 10-20 seconds worth of images
fits in physical RAM. If not, there is no way to keep them around.
What is the actual selection algorithm for pages to be paged out? A
strict LRU, or are there qualifiers based on process, priority, etc?
Another important distinction to make here. Paging out is the act of
synchronising a backing store page (file, swap, etc.) with the
modified contents held by the cache in RAM. Pageout occurs when a
dirty page (one whose contents have been changed vs. the backing
store) is being cleaned, typically prior to being zeroed and placed
on the freelist, which in turn occurs when the freelist falls below
the low water mark.
Pageout matters to you because you are pre-rendering early, meaning
that your pre-rendered images are all held in dirty pages, and once
your working set blows out you have large amounts of dirty memory
that has to be cleaned before it can be recycled as free pages.
Mac OS X uses a modified two-handed clock algorithm over a single
physical memory pool. The most significant variation in your case is
that file cache pages enter the list at the head of the inactive
list, rather than the active list, in order to bias reclamation in
favour of the buffer cache vs. active text/data pages.
Process priority factors indirectly inasmuch as a process whose
threads runs more often has a greater opportunity to claim physical
pages by referencing them. Typically however there tends to be a
poor correlation between thread priority and working set size, so LRU
wins out over any priority oriented scheme. Furthermore, thread
priority is a mutable thing, so there is no good way to know what the
relative priority of a thread is when you can only sample its recent
history.
The bottom line to all of this is that first you must understand what
your application is doing.
Don't worry, I've been studying it for several years now. Its
performance is
widely praised on WinXP, but lags in this area on OS X, something
I'm working
to rectify. I need to understand what OS X is doing to help.
The point that I'm trying to get across is that you are blaming the
OS for something that is fundamentally, if indirectly, your own
fault. Your app is cannibalising itself simply by using too much
physical memory, and you need to understand what it is doing that
causes its working set to blow out in such a fashion so that you can
stop doing it.
It is reasonable (and correct) to assume that Mac OS X is tuned very
carefully to support applications with very large memory footprints,
and that the folks responsible for that tuning understand both the
requirements of that class of applications and how to make the system
work well under those loads. Given that it sounds like this is
important to you, you might want to see what Apple DTS can offer in
the way of feedback tailored to your particular application's behaviour.
= 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