lf-edge
Add task CPU binding
When we deploy a task on the Xen hypervisor we set the number of vCPUs based on what is in the API (which comes to domainmgr as a DomainConfig) and end up with a /run/domainmgr/xen/xen<N>.cfg with vcpus = 1 maxcpus = 1
But for real-time guests we should really pick a particular CPU. That can be done copying the description in https://wiki.xenproject.org/wiki/Xen_3.x_Configuration_File_Options: List of which CPUs this domain is allowed to use; VCPU0 runs on CPU2 & VCPU1 runs on CPU3 cpus = ["2", "3"]
Note that Xen dom0 is bound to use CPU 0, thus need to start assigning at 1.
An initial test might be to always bind to specific CPUs, but to support both real-time and non-real-time workloads I think a subseqent step would be to add e.g., a "bind_cpu" boolean in the API in https://github.com/lf-edge/eve/blob/master/api/proto/config/vm.proto
That way we can still run 10 non-realtime workloads each using one vcpu even though the hardware only has 8 cores.
The code which generates the xen config file lives in https://github.com/lf-edge/eve/blob/master/pkg/pillar/hypervisor/xen.go with type defintions in https://github.com/lf-edge/eve/blob/master/pkg/pillar/types/domainmgrtypes.go
Hey @eriknordmark -- I'm intrigued by these comments, but before we go any further -- let me just ask what makes you worried about the real time use case right now? Is there something in particular you have in mind?
Also, this strikes me as very Xen specific feature that may be difficult to support with exactly the same semantics on KVM (or other hypervisors honestly).
Sure @rvs a hypervisor like ACRN might have reasonable support for real time.I thouht KVM has quite unpredictable I/O realtime characteristics but conceptually CPU binding can apply across the board.
Determining the mechanisms is presumably easiest on Xen, and then see how we expose this in the API.