On May 14, 2021, at 07:12, Christopher Nielsen wrote: > Since we’re overcommitting on CPU, I’m wondering if it would make sense to > reduce the vCPUs in each VM to 4? In addition to reducing any swapping, that > might also reduce the hypervisor context-switching overhead, and improve > build times somewhat. (It’s been awhile, but I think (?) there might be > additional hypervisor overhead from overcommitment.)
My assumption is that that would have the opposite effect. Not all commits or forced builds result in builds on every builder. Some ports are marked as known-fail on some OS versions; others aren't marked but still fail on some OS versions. And because of the way we currently have distfile mirroring set up, all builds trigger a mirror task, even if distfiles are already mirrored, so often several builds are waiting for mirroring tasks to complete. We want to use as many CPUs as possible so builds finish as quickly as possible. If we only end up starting one build, for example, we want it to use 8 CPUs. No point using only 4 CPUs and leaving the rest idle. Using only 4 CPUs but still using 8 GB RAM would convey an assumption that each compile job needs up to 2 GB RAM. If that is a valid assumption, fix it in MacPorts base. It currently assumes one compile job needs up to 1 GB RAM. That assumption was coded a long time ago, but I think it's probably still close to the truth. There are a few ports where that assumption is not true, like tensorflow. We should enhance base to allow ports to override the assumption, like https://trac.macports.org/ticket/62554. Yes I'm sure overcommitment has some kind of overhead in the hypervisor. My assumption is that the developers of the hypervisor are smart and that the amount of overhead is small.
