Re: RAM Cache vs the Pageout Demon
Re: RAM Cache vs the Pageout Demon
- Subject: Re: RAM Cache vs the Pageout Demon
- From: Russ <email@hidden>
- Date: Mon, 23 Oct 2006 12:11:24 -0700 (PDT)
--- 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.
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.
> 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.
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.
> > 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. What is the actual selection algorithm for pages to be paged out? A
strict LRU, or are there qualifiers based on process, priority, etc?
> Without understanding your application, it's difficult to see how you
> can justify holding that much unprocessed image data in memory.
It's an important advantage to speeding overall workflow. And it is often
already partially processed.
> In a followup message, you indicated that you are using third-party
> image loading libraries, and by this I infer that your interface to
> them is along the lines of "render this filename into a buffer".
> This robs you of a good deal of control over your working set size;
> you can pessimistically assume that the library will consume pages
> equal to 2x the size of the file at a minimum. 1x will go straight
> to the inactive queue, 1x will go to the active queue.
The libraries require working store, yes. But of course it is transient and
released (and hopefully reused) once reading the file is done. If the file data
is kept in OS X's file cache, at a higher priority than the app's RAM cache,
that's clearly a problem.
> If you are willing to spend some time analysing these libraries...
This is off-topic. The readers include Quicktime itself, for example. The data
that is read from the file is not necessarily the same as the data in the RAM
cache, it can be worked on substantially, hence the desire to maximize the
cache.
> Given that you can't cache all of them, it
> strikes me as being more sensible to cache many fewer and begin your
> image flip speed reduction earlier, with a progressive slowdown while
> you are reading ahead/behind.
Neither is the app necessarily linear---random frame access is common, which is
why they should be in cache to start.
> Another point to consider; you say "images can be tens of
> megabytes". Do you display images at full resolution, or are you
> scaling them for display?
They are zoomed/panned for display, but they must be kept 100% in RAM for the
processing that is the crux of the application.
> 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.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
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