This seems to be Apple's way of storing data that doesn't run through native ARM applications.
Yes, some applications take a long time to run and some commands given in the console via rosetta take a very long time to perform.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Memory swap usage higher on M1 chips than intel
- Thread starter Kraizelburg
- Start date
- Sort by reaction score
This seems to be Apple's way of storing data that doesn't run through native ARM applications.
Yes, some applications take a long time to run and some commands given in the console via rosetta take a very long time to perform.
What's the term Apple uses to describe the way that the new m-series chips interact with the RAM?
Isn't it "unified memory", or something like that?
Most folks would think that this concept works something like so:
CPU <--> RAM
But I sense that something else is going on here, something that Apple has kept silent about, but which users are finding out now (experiencing an EXTREMELY HIGH degree of RAM/disk swapping, and extraordinarily high disk usage).
My GUESS (and I have no insider knowledge) is that what's REALLY going on with "unified memory" is that "the unity" is between THREE components:
1. CPU
2. RAM
and
3. SSD.
As such, it's more like this:
CPU <--> SSD <--> RAM
Or perhaps that could be perceived as being "a triangle" with CPU, SSD, and RAM at each point.
And, the excessive RAM/disk swapping and excessive SSD wear is actually A PART OF THE DESIGN, using both RAM and SSD to create the impression of "faster response" (instead of RAM alone).
I've offered the suggestion that m1 users ought to try DISABLING VM disk swapping and compressed memory for a little while to observe the results on the drive usage, but so far no one seems willing to take me up on the idea.
Isn't it "unified memory", or something like that?
Most folks would think that this concept works something like so:
CPU <--> RAM
But I sense that something else is going on here, something that Apple has kept silent about, but which users are finding out now (experiencing an EXTREMELY HIGH degree of RAM/disk swapping, and extraordinarily high disk usage).
My GUESS (and I have no insider knowledge) is that what's REALLY going on with "unified memory" is that "the unity" is between THREE components:
1. CPU
2. RAM
and
3. SSD.
As such, it's more like this:
CPU <--> SSD <--> RAM
Or perhaps that could be perceived as being "a triangle" with CPU, SSD, and RAM at each point.
And, the excessive RAM/disk swapping and excessive SSD wear is actually A PART OF THE DESIGN, using both RAM and SSD to create the impression of "faster response" (instead of RAM alone).
I've offered the suggestion that m1 users ought to try DISABLING VM disk swapping and compressed memory for a little while to observe the results on the drive usage, but so far no one seems willing to take me up on the idea.
Unified memory is this:
Code:
CPU <-\
GPU <--\
AMX <---> shared, coherent cache <---> memory controller <---> RAM
NPU <---/
... <-/It's about allowing high memory bandwidth to eery single processor in the machine and enabling ultra-low-latency communication between them.
SSD is around 50 to 200 times slower than RAM. How would one use it to become "faster" than RAM alone?
Well, I did it on my M1 MBA and ... no disk writes from swapping, and an order of magnitude less TBW as a result. Nothing magical or even surprising. Overall, this situation looks like a rather embarrassing kernel bug in the virtual memory management.
ambient wrote:
"Well, I did it on my M1 MBA and ... no disk writes from swapping, and an order of magnitude less TBW as a result. Nothing magical or even surprising. Overall, this situation looks like a rather embarrassing kernel bug in the virtual memory management."
Maybe not magical or surprising, but you're saying that it DID pretty much cut down on the swapping and disk usage? That was "the goal" -- nothing more.
When you say "order of magnitude", what does that mean in actual gigabytes/terabytes...?
"Well, I did it on my M1 MBA and ... no disk writes from swapping, and an order of magnitude less TBW as a result. Nothing magical or even surprising. Overall, this situation looks like a rather embarrassing kernel bug in the virtual memory management."
Maybe not magical or surprising, but you're saying that it DID pretty much cut down on the swapping and disk usage? That was "the goal" -- nothing more.
When you say "order of magnitude", what does that mean in actual gigabytes/terabytes...?
The effect from swap is easy to trace by watching writes from kernel_task and vm_stat swap numbers. For me around 80-90% of writes on my MBA are coming from swapping when it's on. Once I turn the swap off, instead of 200-400Gb daily I get low tens of Gbs.
P.S. it's not specific to M1, similar symptoms are on observed on Intel Big Sur, though somewhat less pronounced.
Rosetta needs to recompile the application from x86 to ARM binary code, so I imagine this might take a little bit of time the first time you start it, especially for larger applications. Do you experience these delays every single time you run the command?
Now, I have no idea, but speculating wildly one could imagine that Rosetta-translated code pages are stored in swap... this would make some sense to me design-wise, but that alone won't make your swap explode like that. Code is fairly small.
Overall, I tend to agree with others here who speculate that this might be a bug.
I agree, and besides, I'd much rather use swapping than go back to pre virtual memory days! Knock on wood, but I've been using SSD's for a long time and I've yet to have one stop working. True, I don't control that many PC's, but still...
Anyway, one question for you as you know a lot more about the M1 than I do. I seem to remember that pages were a lot bigger on the M1 than an intel processor. Am I remembering right? Could that account for some of the extra SSD usage on the M1 vs Big Sur on an Intel machine? Seems to me that could be a part of it. Big pages would cut down on the number of page ops (which is good), but you'd be reading and writing a lot more when you had to do a page op.
Yes, M1 uses 16KB pages as opposed to 4KB memory pages on Intel CPUs. I am not sure however that this can account for the large disparity in SSD writes. Swapping usually affects neighboring pages (e.g. if you swap out application data, you probably swap out a bunch of it), so the total size of data written should remain comparable. Smaller pages could result in lower disk activity if data was written to the SSD at random, but that's never the case.
Last edited:
Interesting, thanks. There's something about that that is tickling my memory. (about disk access in general) I'll have to think about it some more.
I've read the entire discussion through and I've got one question left: what if I have, say, 10GB free on my 256SSD and have heavy SWAP usage (say, I have docker running)?
Does this mean that this swap can use say 8GB (the size of swap) + 10GB free space (ssd controller would magically spread ssd blocks usage). All in all 18GB.
The point is that swap can use only the place it uses at the moment + 10GB free. But these are the same blocks (as 246 GB of blocks are occupied with os and my personal data). The same 18GB blocks, not all 256 blocks. And these blocks will suffer badly and very fast.
Imagine, that I have 10GB writes to swap daily.
Does this mean that in case of 1000 times ssd block rewrites I would have 1800 days of SSD life (18gb / 10 gb * 1000 days)
We can tune the numbers. I can only make an experiment and measure swap consumption in real life.
Sorry if my question/explanation is bad, feel free to ask questions.
As of now I'm afraid of swap to kill my SSD and have to use solutions like remote docker server (on linux) with local docker CLI (on Mac mini m1) and I've lost the ability to mount volumes in docker which I really need
Does this mean that this swap can use say 8GB (the size of swap) + 10GB free space (ssd controller would magically spread ssd blocks usage). All in all 18GB.
The point is that swap can use only the place it uses at the moment + 10GB free. But these are the same blocks (as 246 GB of blocks are occupied with os and my personal data). The same 18GB blocks, not all 256 blocks. And these blocks will suffer badly and very fast.
Imagine, that I have 10GB writes to swap daily.
Does this mean that in case of 1000 times ssd block rewrites I would have 1800 days of SSD life (18gb / 10 gb * 1000 days)
We can tune the numbers. I can only make an experiment and measure swap consumption in real life.
Sorry if my question/explanation is bad, feel free to ask questions.
As of now I'm afraid of swap to kill my SSD and have to use solutions like remote docker server (on linux) with local docker CLI (on Mac mini m1) and I've lost the ability to mount volumes in docker which I really need
There is no such thing as “swap size”. Swap will use as much space as the OS will deem necessary. If you run out of SSD space, it will start closing down applications instead.
Also, having only little space left does not mean that those SSD cells will be hit hardest. SSDs are over-provisioned - they include a bunch of cells that do not count towards the total SSD size, and the controller is dynamically remapping the addresses to ensure that cells degrade gradually.
It is likely that the swap behavior is not unintentional, although likely to be improved as part of Apple's continual tuning. macOS and Linux in general always swap and buffer more than Windows.
I think the worry about SSD wear is overblown: How worried should you be about your M1 Mac’s SSD lifespan?
I think the worry about SSD wear is overblown: How worried should you be about your M1 Mac’s SSD lifespan?
Didn't know about SSD overprovisioning, thanks for the hint. Anyway, the less free space I have the more intensive wear out I got even on those "extra blocks".
Sorry for an offtop but can I somehow disable swap like I did on Intel Mac? The recipe I used for Intel Mac seems to be not working (changing vm_compressor mode in bootargs) for M1.
I've read that Apple has refactored the boot process completely and maybe now it doesn't respect this boot argument?
Sure, for systems where you can remove your SSD and change it to another one.
Apple soldered everything in the motherboard, in that case, when you have running docker and 20 containers with complicated services start talking to each other (exchanging data, writing and reading from SSD), you have 4 diffirent databases plus inmemory databse and many many other applications up and running, you are starting to worry, WTF Apple came up with again that SWAP is up to 10GB and RAM is 10% occupied ..
This is a normal situation ? Convince everyone that such SSD will not be murdered with constant reading and writing from SWAP after dunno, 2 years ? This is not just SWAP, SSD is used instantly by operating system services in the background..
You point to article from Jon Jacobi from MacWorld. A gentleman who probably gets paid to talk about apple hardware in superlatives
Last edited: