Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

leman

macrumors Core
Oct 14, 2008
19,518
19,669
Swap is absolutely NOT a backup to your memory and it certainly isn't in OS X. Swap is just memory on disk and it is quite useful. Why? Because it frees up actual memory. It is something that is heavily used in virtualisation products because it makes far more efficient use of memory than without it. Swap is more like a parking lot where you can park stuff that you don't quite actively use.

That is precisely what is meant with "back up for RAM". Its not "backup" (as in create safe copy), its "backing store", as "storage that acts as the final guarantee for memory". Please read the 'About the Virtual Memory System" subsection carefully in the document that you yourself have linked.

What you are describing is only part of the story. Memory management is not something that is only done by the OS for very obvious reasons. The app knows about its memory, the OS doesn't and vice versa. Therefor they have to work together. That's why apps can use more memory than they need and why they return memory when other apps need it more. And that's also why they are able to swap. The app requests the OS to swap.

Again, you seem to be confused about a number of things. Most importantly, you seem to be confusing physical memory and virtual memory address space (which have nothing to do with each other).

An app on OS X can give the OS certain hints about how the RAM will be used. It definitely cannot request the OS to swap. Nor does it take any active role in swapping (this is done with processor traps or proactively by the OS). Before advising people to read developer documentation you should do it yourself. Also note that memory management on OS X and iOS is different because iOS does not have a backing store and thus iOS apps need to take care of low memory situations themselves.
 

dyn

macrumors 68030
Aug 8, 2009
2,708
388
.nl
Again, you seem to be confused about a number of things. Most importantly, you seem to be confusing physical memory and virtual memory address space (which have nothing to do with each other).
Then you have not understood neither my post nor the documentation concerning virtual memory. Read the chapter called "About Virtual Memory" from the following documentation: About the Virtual Memory System.

Also note that memory management on OS X and iOS is different because iOS does not have a backing store and thus iOS apps need to take care of low memory situations themselves.
Possibly but as the documentation says:
This document provides background information about the memory systems of OS X and iOS and how you use them efficiently.

Ergo: if you haven't actually read the documentation, don't blame someone who did for not reading it just because you don't agree with it. If you don't agree with how the memory system works then talk to Apple. It is their documentation and their system, not mine. I'm also not the first and only to be pointing at these documents, it has been done a lot of times in various topics concerning OS X and memory. And yet, people are still thinking the memory system is a simple thing; it isn't.
 

leman

macrumors Core
Oct 14, 2008
19,518
19,669
Then you have not understood neither my post nor the documentation concerning virtual memory. Read the chapter called "About Virtual Memory" from the following documentation: About the Virtual Memory System.

Buddy, I have a degree in computer science. I also used to know a bit about CPU design, have programmed a memory allocator or two and dabbled a bit in kernel programming. I have also looked at the FreeBSD code that implements virtual memory (which is in the OS X kernel). I am certainly not an expert in this area but believe me, I have at least a basic understanding about how it works. And what you say does not make much sense to me. Just because you can quote the developer documentation out of context does not mean that you have understood what the documentation is about.

Anyway, you are welcome to quote the relevant bits of documentation which allow the application to "request the OS to swap".
 

Fishrrman

macrumors Penryn
Feb 20, 2009
29,235
13,305
I solved any problems with "swap" in Yosemite.
I completely disabled it! (using terminal)
No swapping at all!

Got enough RAM installed, not a single crash to date.

Also disabled compressed memory, disabled Spotlight (no disk thrashing).

Running fine here...
 

simonsi

Contributor
Jan 3, 2014
4,851
735
Auckland
I solved any problems with "swap" in Yosemite.
I completely disabled it! (using terminal)
No swapping at all!

Got enough RAM installed, not a single crash to date.

Also disabled compressed memory, disabled Spotlight (no disk thrashing).

Running fine here...

Good luck, that was pointlessly dangerous IMHO. Btw "thrashing" means lots of paging/swapping being carried out, it has had that meaning for 30+yrs :)

What do you think will happen when, eventually, your system needs to swap? (Which is more likely as you have turned off compression too).

Terrible "fix" for a non-problem.
 
Last edited:

simonsi

Contributor
Jan 3, 2014
4,851
735
Auckland
Well, you are wasting RAM. In my above example, keeping the indexing daemon data in the RAM can be wasteful because the same RAM can be used, say, for caching while the daemon is inactive. Restoring the deamon from swap is of course marginally slower than from RAM, but it does not matter, as it is not a time-critical application. Swapping the deamon data to disk is extremely efficient, because only changed pages needs to be saved, most of the saved state remains unchanged and does not need to be touched.



Again, I do not think that this is true. If swapping does not degrade performance, but actually frees up system resources while optimally using them, then it is the optimal solution. Unless you really have tons of RAM. The cost/benefit equation is quite fragile here.

From the Developer doc linked several times:

"Paging of any kind, and disk thrashing in particular, affects performance negatively because it forces the system to spend a lot of time reading and writing to disk."

IF you need to page (or predict needing to page), then using low-priority I/O etc makes absolute sense however "needing to page" means you are already off the optimal strategy which would avoid needing to page in the first place. If a process finds it needs to page immediately then its performance will be degraded while that paging occurs.
 

simonsi

Contributor
Jan 3, 2014
4,851
735
Auckland
Memory management is not something that is only done by the OS for very obvious reasons.

Here is the crux, "memory management" is carried out by the OS and Apps. But the memory they are talking about is different in each context and the amount of control and decision-making they carry out is not the same.

You should understand that the page-fault handler is OS code, not App code, you might need to re-read that Virtual Memory doc with that in mind.

Apps manage their own memory allocation and request resources from the OS, sometimes on a predictive basis but they generally just run their own address space.

Having the App make decisions based upon detailed knowledge of the state of the system resources and other apps would subvert the entire point of the OS and cause contention and worse.

The OS manages the system resources and makes paging decisions via the page-fault handler.

Read the section on Paging <very> carefully and you will see it is the kernel making paging decisions, not any App, they simply make requests from the OS which it then manages and acts upon.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.