I'm spec-ing a new MacBook Pro and want to know how much memory my workload requires. I'm doing my development work on a 2011 iMac with 16GB of RAM and want to know if I need that much memory for my new MBP since RAM is not upgradable.

I created a 8GB RAM disk and a random 7GB file to see the memory pressure on my Mac:

diskutil erasevolume HFS+ 'RAM Disk' `hdiutil attach -nomount ram://16777216`
dd if=/dev/urandom of=temp_7gb bs=1 count=0 seek=7g

To my surprise, it had almost no impact on the memory pressure chart in Activity Monitor! Am I doing this right? How can I simulate that my current Mac only has 8GB of memory?

  • 9
    I would be cautious with buying a computer with "only 8 GB" of RAM in 2019. While it's certainly sufficient for most things today, you have to think about 2-5 years from now. With the prominence of heavy JavaScript on sites, and everyone writing shit-tier electron apps, RAM is going to be a valuable resource to have. – Alexander Oct 13 '19 at 15:25
  • @klanomath it's to create a 7GB file with random bytes. I pilfered it from some forum so it may not do what I want – Mike Henderson Oct 13 '19 at 16:25
  • 2
    @MikeHenderson: That command skips over the first 7G of the file (seek=7g) and then writes 0 blocks (count=0) of size 1 octet (size=1). In other words: it will write nothing at all. All it does is create a sparse file with a 7G hole at the beginning and no content otherwise. The whole size of the file will be negligible (basically just the metadata for describing the "hole"). – Jörg W Mittag Oct 14 '19 at 4:38
  • 2
    Do you want this new MBP to last you a few years? Is your workload and software going to remain exactly consistent for that time? Always over-estimate – Darren H Oct 14 '19 at 13:35
  • Just FYI: MacPerformanceGuide.com : His professional photographer's demands and technical competence informs his technically Insightful, detailed review of and commentary on Mac hardware and OS. I visit this site frequently. – radarbob Oct 14 '19 at 19:36

Open Terminal, enter:

sudo nvram boot-args="maxmem=8192"

and reboot. This will limit the RAM to 8 GiB. Now start using your Mac with the usual workload.

To reenable the full 16 GiB-RAM simply enter sudo nvram -d boot-args and reboot again.

Your dd-command won't work as intended, because the number of blocks written is 0 (count=0) and the block size would be 1 Byte (bs=1). As far as I can tell only a "file" with the size of 7 GiB is created in the file system catalog but no data is written to the file itself at all. If the count would be 1 (count=1), 1 Byte of random data would be appended to the file temp_7gb (seek=7g).

The destination (of=temp_7gb) is dubious. It creates a file in the working directory. You either have to cd to a file system on the RAM disk (e.g. cd /Volumes/RAM-Disk/) first to create the file there or write directly to the RAM-disk device (of=/dev/devX).

dd is a tool which rather measures disk I/O than CPU load/speed or memory usage/pressure.

With a clever combination of dd operands you still can use it to simulate CPU load/memory usage.

  1. if=/dev/urandom or if=/dev/zero are related with the CPU speed
  2. of=/dev/null the disk won't be involved.
  3. bs=x determines the memory usage (x is almost proportional to memory usage)
  4. count=y gives you time to test things


dd if=/dev/urandom of=/dev/null bs=1 count=1000 

mainly measures the system-call overhead (including any Spectre / Meltdown mitigations your kernel uses, which make system calls slower than they used to be). Cryptographically-strong random numbers also takes significant computation, but 1 system call per byte will dominate that. The memory footprint is low (on my system about 400 kB)

dd if=/dev/urandom of=/dev/null bs=1g count=10

mainly measures the CPU speed because it has to compute a lot of random data. The memory footprint is high (on my system about 1 GB). bs=1m would be about the same but use much less memory.

dd if=/dev/zero of=/dev/null bs=1g count=10

mainly measures the memory bandwidth (here ~7 GB/s) for the kernel's /dev/zero driver doing a memset in kernel space into dd's buffer. The memory footprint ~= buffer size, which is much larger than any caches. (Some systems with Iris Pro graphics will have 128MiB or 256MiB of eDRAM; testing with bs=128m vs. bs=512m should show that difference.)

The kernel's /dev/null driver probably discards the data without even reading it so you're just measuring memory write bandwidth, not alternating write + read. (And system-call overhead should be negligible with only a read+write per 1GiB stored.)

dd if=/dev/zero of=/dev/null bs=32k count=100000

mainly measures the CPU Cache-write bandwidth (here ~13 GB/s) and system-call overhead. The CPU has not much to compute (zeros!); the memory footprint is low (on my system about 470 kB).

L1d cache size is 32kiB. You'd think bs=24k would be faster (because it fits easily in L1d instead of having more evictions because dd's buffer isn't the only thing in L1d), but increased system-call overhead per kB copied might make it worse.

L2 cache is 256kiB, L3 is 3 to 8 MiB. bs=224k should see pretty good bandwidth. You can run dd on each core in parallel and bandwidth will scale because L2 caches are per-core private, unlike shared L3 and DRAM. (On many-core Xeon systems, it takes multiple cores to saturate the available DRAM bandwidth, but on a desktop/laptop one core can come pretty close.)

  • The OP's 2011 iMac has a CPU with an integrated memory controller, like all x86 CPUs since then. DRAM bandwidth is not necessarily the same as bandwidth to the southbridge, and reading from /dev/zero in 1GB chunks is mostly just making the kernel do a big memset. (And discard the result). en.wikipedia.org/wiki/Intel_QuickPath_Interconnect has a diagram that shows QPI is for system <-> DRAM or CPU, not for CPU <-> DRAM. – Peter Cordes Oct 14 '19 at 2:05
  • And BTW, bs=32k bottlenecks on system-call overhead as much as the minimal cost of a 32kB memset. With Spectre + Meltdown mitigation, system calls overhead is significantly higher. 13GB/s is laughably low for cache write B/W on one core. Even though L1d size = 32kiB, you'd probably see dd throughput go down if you shrink it to 24k so you're more likely to get all L1d hits, no evictions. Or go up if you grow it to bs=224k (just below L2 size of 256kB). These are Intel's cache sizes since Nehalem. – Peter Cordes Oct 14 '19 at 2:08
  • @PeterCordes :-) While writing the dd-addendum, I knew that some assesments may be bold. Before appending it to the answer I indeed visited the linked wikipedia article because I didn't really knew, how modern CPUs are linked to the main memory (I knew: no FSB+NB anymore). Most important - I had it on the tip of my tongue, but I needed someone else to mention it - are the words system-call overhead. I'll try to improve the answer - feel free to do the same (with more expertice than I have). – klanomath Oct 14 '19 at 3:43
  • Sure, added a suggested edit. I have gold badges in [performance], [x86-64], and [cpu-architecture] over on Stack Overflow so you can probably take my word for it :) – Peter Cordes Oct 14 '19 at 4:11
  • @PeterCordes Considering the weighting between the boot-args answer (4%) and the dd-digression (96%) (the result of a sloppy forum article: Mike Henderson's comment: ... I pilfered it from some forum so it may not do what I want), we have to modify the question now ;-) – klanomath Oct 14 '19 at 4:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .