site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com --- Michael Smith <msmith@freebsd.org> 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. 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. 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. What is the actual selection algorithm for pages to be paged out? A strict LRU, or are there qualifiers based on process, priority, etc? The bottom line to all of this is that first you must understand what your application is doing. = 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... On Oct 23, 2006, at 12:11 PM, Russ wrote: 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) 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. 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. 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. 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. This email sent to site_archiver@lists.apple.com