I also agree with Hugh in that there are no container limits to follow, only those created by what the hardware resources can support. If the device is running low on CPU I imagine device API calls response time will be impacted, even cause timeouts, but more significantly local mode builds will be slowed. Live Push is intelligent enough to only execute commands that achieve your newest change and they are done inside the container. This means no image is being built so shouldn’t need a lot of CPU but if your change is to download and compile a new dependency then that could be affected.
It definitely sounds like you want to get the most out of the hardware you have which is awesome. I think we should try experimenting with the various CFS scheduler options from https://docs.docker.com/config/containers/resource_constraints/#configure-the-default-cfs-scheduler. We could run high CPU containers in their own cores via
cpuset-cpus and limit their usage via
cpus. This could allow other processes to not become blocked.
However, I believe this only works if live push, local mode builds, the OS, and supervisor all don’t run on the core we designated as the high load core. Try seeing where these services are running and if we can achieve the above core separation. I’ll look into this myself and see if this is a good idea / possible!