>Starting with 4 virtual cores and 8 GB vRAM, where the VM ran perfectly briskly with around 5 GB of memory used, I stepped down to 3 cores and 6 GB, to discover that memory usage fell to 3.9 GB and everything worked well. With just 2 cores and 4 GB of memory only 3.1 GB of that was used, and the VM continued to handle those lightweight tasks normally.
Good reminder that there's a certain amount of memory tied up with each core (probably mainly page cache and concurrency handling etc).
macOS is generally pretty amazing at efficient memory usage and VM (virtual memory subsystem) handling. So even a 8GB machine can run pretty impressive workloads without having the user think the machine is underpowered.
Not really. Larger page sizes mean more potential for wasted memory and it has had a long standing memory leak in some core component to where even Calculator can cause an OOM event.
If guest memory can be reclaimed, it doesn't need to be paged to disk once you hit RAM contention. It's mostly saving accounting overhead, but it'll have some effect on latency, which you're more likely to perceive under contention.
Honestly macOS probably can go much lower than that if you turn off some stuff that's not strictly necessary for a VM. The first iPhones only had 128 MiB of RAM and they ran a trimmed down version of macOS Tiger I believe. It's just that RAM has been quite abundant so far, so there was no real reason to try to trim it down, but it's definitely possible, and probably not that hard either, we just need to start trying again :)
Recently got a Mac Mini for local CI purposes (together with Forgejo Actions), took a broad look at the ecosystem and decided to just roll with "build on host" instead. Setting up signing/notarization just looked like an insurmountably task together with isolating it from the host, even with agents. At least the macOS builds are really fast now and the signing/notarization just ~200 lines of Bash...
I'm wondering if the Xcode simulator (without Xcode running) performs as well, my 2020 Intel MacBook Air has been incapable of running Safari in iOS smoothly for nearly all its life.
https://github.com/trycua/cua/tree/main/libs/lume had a interesting take on this.
>Starting with 4 virtual cores and 8 GB vRAM, where the VM ran perfectly briskly with around 5 GB of memory used, I stepped down to 3 cores and 6 GB, to discover that memory usage fell to 3.9 GB and everything worked well. With just 2 cores and 4 GB of memory only 3.1 GB of that was used, and the VM continued to handle those lightweight tasks normally.
Good reminder that there's a certain amount of memory tied up with each core (probably mainly page cache and concurrency handling etc).
Got a M5 air recently - my first dive into MacOS land so trying to figure this out too.
Seems essentially impossible to get:
* pytorch
* GPU acceleration
* VM/container like isolation
The virtio-gpu layer gets closest but seems to only pass through graphics GPU not compute GPU so no pytorch
> Starting with 4 virtual cores and 8 GB vRAM, where the VM ran perfectly briskly with around 5 GB of memory used
But... if you start applications inside your VM it will want the full 8 Gb you've allocated not the 5 Gb it uses at startup?
I don’t assume that macOS virtualization is advanced enough to support memory ballooning, or is that not what you’re referring to?
Edit: I stand corrected!
I don't assume anything either, but a single Google search is enough to dispel that [1]
[1] https://developer.apple.com/documentation/virtualization/vzv...
macOS is generally pretty amazing at efficient memory usage and VM (virtual memory subsystem) handling. So even a 8GB machine can run pretty impressive workloads without having the user think the machine is underpowered.
Not really. Larger page sizes mean more potential for wasted memory and it has had a long standing memory leak in some core component to where even Calculator can cause an OOM event.
What will that help with if the host and guest combined need > physical ram?
If guest memory can be reclaimed, it doesn't need to be paged to disk once you hit RAM contention. It's mostly saving accounting overhead, but it'll have some effect on latency, which you're more likely to perceive under contention.
Honestly macOS probably can go much lower than that if you turn off some stuff that's not strictly necessary for a VM. The first iPhones only had 128 MiB of RAM and they ran a trimmed down version of macOS Tiger I believe. It's just that RAM has been quite abundant so far, so there was no real reason to try to trim it down, but it's definitely possible, and probably not that hard either, we just need to start trying again :)
My only experience with VMs on macOS is colima+docker, and it's relatively painful and inefficient (but usable).
Recently got a Mac Mini for local CI purposes (together with Forgejo Actions), took a broad look at the ecosystem and decided to just roll with "build on host" instead. Setting up signing/notarization just looked like an insurmountably task together with isolating it from the host, even with agents. At least the macOS builds are really fast now and the signing/notarization just ~200 lines of Bash...
> the signing/notarization just ~200 lines of Bash
200 lines?! That’s two orders of magnitude too many. What exactly are you doing that you need so such code for signing and notarisation?
Could you share your recipe please ? I’m interested
I'm wondering if the Xcode simulator (without Xcode running) performs as well, my 2020 Intel MacBook Air has been incapable of running Safari in iOS smoothly for nearly all its life.