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

padapada

macrumors regular
Original poster
Is there a way to reliably limit MacOS to 8GB on a MacBook Air that has more? It would let me experience 8GB.
 
Is there a way to reliably limit MacOS to 8GB on a MacBook Air that has more? It would let me experience 8GB.
I couldn’t give you any detail but I saw on another (closed) forum that someone made a RAM disk with RAMdiskcreator tool, to leave 8GB outside the RAM disk, for the same reason.
 
someone made a RAM disk with RAMdiskcreator tool, to leave 8GB outside the RAM disk
That won't work. First, the RAM Disk does not consume RAM unless it has been written to. Even if it has, the OS will compress the RAM disk's memory and eventually swap it out to give you back the full 16GB of RAM.
 
  • Like
Reactions: Basic75
Is there a way to reliably limit MacOS to 8GB on a MacBook Air that has more? It would let me experience 8GB.

No, not if you want to simulate how it is to use a MBA with 8Gb of RAM.

What some people do is to create something which uses 8Gb of memory, but it's not the same.
 
That won't work. First, the RAM Disk does not consume RAM unless it has been written to. Even if it has, the OS will compress the RAM disk's memory and eventually swap it out to give you back the full 16GB of RAM.

As I said I don't know the detail of what he did but he seemed quite satisfied that it had worked. Maybe he did fill the RAM disk. He had 96GB of RAM and made an 88GB RAM disk.

How long would it take for compression to take effect? maybe it is long enough to be able to assess 8GB of RAM for a while.
 
You could use a virtual machine, but depending on what you use memory may be allocated dinamically. I was doing some tests with UTM and at least CPU cores, despite being allocated equally, were being shared dinamically (the power was split only if actually used in the VM as tested by doing benchmark on just the host or both).
 
That won't work. First, the RAM Disk does not consume RAM unless it has been written to. Even if it has, the OS will compress the RAM disk's memory and eventually swap it out to give you back the full 16GB of RAM.
Yea, RAM disk must be filled up to consume its allocated memory space. If the RAM disk has open files that are active the memory management will leave it alone and not compress it. No matter, another way to do this is to use Terminal and the memory_pressure command to reserve space and hold onto to it for a specified amount of time so one can test the Mac with a reduced memory footprint for user. See below... I found this to be acceptable for testing on my M3 Ultra Studio leaving just about 8GB of memory for me to test over a period of 1hr.

=================================
bxs@Mac-Studio ~ % memory_pressure -p 8 -s 3600
The system has 103079215104 (6291456 pages with a page size of 16384).

Stats:
Pages free: 4253318
Pages purgeable: 108515
Pages purged: 14517828

Swap I/O:
Swapins: 0
Swapouts: 0

Page Q counts:
Pages active: 645673
Pages inactive: 508455
Pages speculative: 136022
Pages throttled: 0
Pages wired down: 388581

Compressor Stats:
Pages used by compressor: 301745
Pages decompressed: 4995791
Pages compressed: 10731888

File I/O:
Pageins: 11428748
Pageouts: 15762

System-wide memory free percentage: 88%

CMD: Allocating pages to go from 88% to 8% percent free
=================================
 
The examples I've seen of people trying generally lead to a worse perception than that from people who actually have 8GB machines. Some of it might be a bias due to people capable of hacking their machine in that way having higher expectations than people who buy base hardware or hold onto old equipment, but I also think it indicates that the methods used aren't reliable.

MacOS is very sophisticated in how it manages resources and I don't think it responds well to kludgy modifications.
 
  • Like
Reactions: 4sallypat
The examples I've seen of people trying generally lead to a worse perception than that from people who actually have 8GB machines. Some of it might be a bias due to people capable of hacking their machine in that way having higher expectations than people who buy base hardware or hold onto old equipment, but I also think it indicates that the methods used aren't reliable.

MacOS is very sophisticated in how it manages resources and I don't think it responds well to kludgy modifications.
I now have my Neo and can compare its actual memory management with the Terminal's Apple provided memory_pressure program use on my M3 Ultra Studio to configure just 8GB of memory for it. Yea, the M3 Ultra has many more cores than the Neo where both are running with the 8GB memory, so the M3 Ultra will perform better with its 8GB compared to the Neo with its 8GB memory. My focus doing the testing on the M3 Ultra is to monitor the memory pressure that Activity Monitor provides.

So with Screen Sharing, Pages, Activity Monitor, Terminal, Safari, Messages, News, Photos and Preview open the M3 Ultra started to see some memory pressure with having just the 8GB of memory to manage, and with zero swapping. What Apps that were running prior to launching the memory_pressure had most of their memory compressed to make way for memory_pressure grabbing some 88GB of memory to simulate having just 8GB free of the 96GB.

Comparing the memory pressure on both the M3 Ultra and the Neo both exhibited similar memory pressure, and the Neo kept chugging along with hitting severe memory pressure that would have shown up in the Activity Monito's MEMORY PRESSURE graph as red.

Here's the memory pressure on my M3 Ultra doing the test
Screenshot 2026-03-11 at 8.12.39 PM.png


...and here's the memory pressure (taken twice) on Neo running a similar workload as was being done on the M3 Ultra

Screenshot 2026-03-11 at 8.28.18 PM.png
Screenshot 2026-03-11 at 8.12.39 PM.png
 
Write a C program that uses malloc() to allocate memory followed by mlock() to pin the pages which prevents them from being compressed or paged out.
 
Just compile this and run in terminal after changing the size to how much memory you want to "remove" from the system.
C:
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/mman.h>

int main()
{
   size_t size = 1073741824;
   void *ptr = malloc(size);
   if (!ptr) {
      fputs("malloc failed\n", stderr);
      return 1;
   }
   int res = mlock(ptr, size);
   if (res) {
      fputs("mlock failed\n", stderr);
      return 1;
   }
   fputs("memory allocated and locked\npress ctrl-c to quit\n", stderr);
   while (1) {
      sleep(3600);
   }
   return 0;
}
 
  • Like
Reactions: Approved and bxs
Write a C program that uses malloc() to allocate memory followed by mlock() to pin the pages which prevents them from being compressed or paged out.
Yes, that is another way for sure but requires one to write a program to malloc() and lock the memory allocation requested.
 
Just compile this and run in terminal after changing the size to how much memory you want to "remove" from the system.
C:
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/mman.h>

int main()
{
   size_t size = 1073741824;
   void *ptr = malloc(size);
   if (!ptr) {
      fputs("malloc failed\n", stderr);
      return 1;
   }
   int res = mlock(ptr, size);
   if (res) {
      fputs("mlock failed\n", stderr);
      return 1;
   }
   fputs("memory allocated and locked\npress ctrl-c to quit\n", stderr);
   while (1) {
      sleep(3600);
   }
   return 0;
}
Thanks for that... appreciated.👍
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.