Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Strange behaviour of mmap() in OS X

On Sunday, June 22, 2003, at 10:52 Uhr, Jim Magee wrote:
On Sunday, June 22, 2003, at 4:36 AM, Marcel Weiher wrote:
[fairness]

You seem to be making the assumption here that "fairness" is an inherent good. I feel no inherent moral imperative for treating memory pages fairly.

Sorry, I didn't mean to make any moral judgments.

;-)

It also has the benefit of being quite predictable. Where it isn't desired, there are simple ways around it (as I pointed out with msync(), and the no-cache fcntl() options).

What I am trying to point out is that there are important (and probably not too uncommon) cases where it tends to do very, very badly (as also shown be the other poster). And the only way to get it to behave is to effectively manage memory manually (and inefficiently in the presence of sufficient RAM), thereby removing one important advantage of a VM subsystem.

Other algorithms, many of which have been (and continue to be considered), tend to make prediction of the policy more difficult for the multimedia software that is the bread and butter of Mac OS X.

...well I found the current behavior to be much more unpredictable...

And lets face it, when you try to run those kinds of applications on a system that is by nature way over-committed in memory resources, being able to predict the default behavior is important.

Exactly!

[mapped pages are already 'punished']

In theory, maybe. In practice, the system will push everything else out of RAM onto disk in favor of the mapped file.

If the current application _needs_ to bring in a bunch of mapped file pages in order to function properly, it better be able to.

Disagreement: this is a multi-tasking operating system, so one *normal* user task should definitely NOT be able to completely hog system resources like that, unless it is given special leave to do so. I can (somewhat) agree that it should be possible to allow it to do so, but definitely NOT as the default behavior!

If that means we had to swap some not-used-recently heaps from other applications - so be it.

Swapping out 'some not-used-recently' heaps would be OK but was not what was happening. Maybe my radar wasn't clear enough on this: everything was getting swapped out. Completely.

A little thrash when the user actively switches apps is better than denying an opportunity for an application to run at all in the limited resources available to it.

But that is exactly what is happening with the current policy.

And, again, for many of the key [data intensive] multimedia applications in our key markets, running degraded is worse than not running at all.

That is exactly what I am asking for and exactly what is not happening. Let's review Alexander's report:

mmap() seems to allocate and retain memory very aggressively in OS X. When I mmap() a large file (~200 MB in size) read-only and access it sequentially from start to end, the RSIZE of my program quickly grows to the size of the file. If the free physical memory is insufficient to accomodate the whole file, the system starts swapping heavily: first other data is paged out (running applications etc), then (after my application has finished and when the paged-out applications are needed again) it has to be swapped back in. During this time, the system is very unresponsive. The whole process can take several minutes.

Huh? The assumption you seem to be making here is that with sequential, we need to know exactly when a page is 'done' so we can then immediately discard it. Why? All that is necessary is to know that when memory is tight, you start discarding sequential pages from the start of the sequential region. No clairvoyance required!

Surely you don't mean "and take ALL the sequential pages (including the ones the app hasn't finished with yet)
before we take ANY pages that need to be swapped (even though the pages that need to be swapped are MUCH older and not currently needed)?"

If you *know* that the pages are older, then go ahead (inactive pages are probably a good bet, right?). As to "taking ALL the sequential pages first", well: yes and no. Yes, that could be an extreme consequence of what I am saying, but no, it seems very unlikely that this will happen: when you are sequentially scanning the file, you will have earlier pages that should satisfy the needs of the scanning for fresh pages.

If you don't, then your working set is larger than available RAM and you are hosed anyway, thrash away. However, currently it manages to go off into thrash-city even if the actual working set is significantly smaller than available RAM.

So I think the policy is superior to the current behavior even at the "surely not" end.

But anything else does require some clairvoyance again. Again, how far back do we need to keep?

I think that "what do we keep" is the wrong question. The correct question is: where do we *start* to remove. This will get you the correct behavior if you have enough memory for the working set, and will only get you into trouble when you are so severely RAM constrained that it doesn't matter, you won't be able to do a good job anyhow. Whereas, again, the current policy fails much earlier.

Believe me.

Believe me, I am trying, I really am. But I also have to believe what my eyes are seeing and my benchmarks are measuring. Maybe there are some effects/conditions that you haven't considered?

Many algorithms that try to guess at the relative importance of "slightly" older sequential pages vs. "much" older swappable pages have been examined. For instance, ones that age sequential pages 2, 3, or even 10 times faster than other [swappable] pages have been tried and STILL tend to push the system over the knee of the swapping curve anyway.

I don't doubt what you say, but have to point out that quite apparently there are a number of OSes that manage this just fine.

Worse, they also tend to cut the knees out from under multimedia applications much sooner (often long before a crisis really exists).

This I have a very hard time believing, because what I was looking at *was* a media application, and it was the current policy that was cutting it off way before there ever should have been a crisis. So my observations and measurements were exactly the opposite of what you are saying.


So, after all that, we have found that there are far fewer applications that benefit from those altered algorithms than not. And most of those are much simpler, and can easily be modified to describe their desire to NOT participate in LRU for a particular set of pages.

The problem is that they do want to participate in LRU. It just shouldn't prefer the entire larger-than-RAM file over everything else in the system. After all, a normal app also doesn't get 100% CPU when there are other runnable processes. Why should it get all of RAM for that one file?

[..]

After all this well-mannered debate,

Sorry, but having to go back to a Mac OS 9 manual VM swapping implementation on OS X left a bit of an emotional scar... ;-)

it seems it comes down to an issue of you liking the semantics of madvise() for making that indication rather than msync().

Well, that's not just a matter of "liking". Msync() takes the decision out of the hand of the OS, meaning that you are manually managing memory. Which means going to disk even when there is no actual need to do so because sufficient real memory for the working set is available (or effectively implementing a complete new VM subsystem on top of the one already in the kernel).

I'll see what I can do to make both equally as effective.

That would be great! :-))

Cheers,

Marcel
_______________________________________________
darwin-development mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-development
Do not post admin requests to the list. They will be ignored.
References: 
 >Re: Strange behaviour of mmap() in OS X (From: Jim Magee <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.