Deep dive

Linux VM CPU Performance on Apple Silicon: How Core Allocation Actually Works

Why ARM VMs perform the way they do covers the architectural reasons — EL2, two-stage memory translation, hardware-assisted interrupts. This is a narrower, more practical question that sits on top of that: when you set a workspace's vCPU count, what does macOS actually do with it, and does adding more always help?

There's no such thing as an efficiency-core vCPU

Apple Silicon's performance and efficiency cores are central to how the chip manages power and throughput on the host — but a virtual CPU assigned to a Linux guest doesn't get a choice between them. Research into how macOS schedules virtualized cores (documented in detail by The Eclectic Light Company) found that every vCPU under Virtualization.framework is treated as equivalent to a P-core: there's no mechanism to place a guest's virtual CPU on an E-core at all. On the host side, physical core assignment follows the same pattern real high-priority processes get — P-cores first, spreading across clusters, falling back to the two E-cores only once the P-cores are saturated.

The practical read: a vCPU isn't pinned to one physical core for its whole life. It behaves like a high-QoS thread that the host scheduler places across available P-cores as load shifts — which is exactly why VM CPU performance tracks host P-core availability so closely, and why background load on the host (another app doing real work) can visibly slow a VM down even though nothing about the VM's own configuration changed.

What that means for choosing a vCPU count

Requesting more vCPUs than the host has P-cores to give doesn't get you E-core capacity as a fallback the way host-native multithreaded work sometimes effectively does — it gets contention, vCPU threads competing with each other and with the host's own P-core work for the same limited pool. Velo clamps whatever you request into VZVirtualMachineConfiguration.minimumAllowedCPUCount and .maximumAllowedCPUCount, the framework's own bounds, but staying under the framework ceiling doesn't mean staying under the point of diminishing returns — that ceiling is a hard framework limit, not a performance recommendation.

Velo's own built-in workload profiles reflect this rather than defaulting everything to the framework maximum: Study & Office defaults to 2 vCPUs, Code & Build to 4, DevOps Lab to 6, and AI Sandbox — the one profile actually expected to run parallel, CPU-heavy work — to 8. None of those numbers are arbitrary round figures; they track what each workload realistically parallelizes, not "as many as the framework allows."

Single-threaded work doesn't care how many vCPUs you assigned

This follows directly from the scheduling model above but is worth stating plainly, because it's the single most common way people misconfigure a workspace: a workload that's fundamentally single-threaded — a slow shell script, a compiler pass that isn't running in parallel, most quick interactive tasks — gets no benefit whatsoever from a higher vCPU count, because only one of those virtual CPUs is ever doing anything. More vCPUs help exactly to the extent that the guest workload is actually parallel: a multi-threaded build (make -j, parallel test runners), a service handling concurrent connections, or several separate processes genuinely running at once.

Before raising a workspace's vCPU count to fix a slow task, check whether the task is actually using more than one core inside the guest — htop or nproc-aware tooling makes this immediately visible. If it's pegging one core while three sit idle, more vCPUs won't fix it; the fix is making the work itself parallel, or accepting that it's a single-threaded ceiling.

Putting it together

Size vCPUs to actual parallelism, not to "more is safer" — a single-threaded task sees zero benefit above one core, whatever the VM's total vCPU count is.
Watch host contention, not just the VM's own configuration — heavy work on the host competes with the guest for the same P-core pool, and a VM that felt fast yesterday can feel slower today with nothing about the VM itself having changed.
Match vCPU count to the workload class, the way Velo's own profiles do — 2 for light interactive use, 4 for a typical build, 6–8 for something genuinely parallel like a DevOps pipeline or an AI workload.