On Wed, Jul 7, 2021 at 1:55 PM Jens Freimann <jfreiman@redhat.com> wrote:
On Wed, Jul 7, 2021 at 12:48 PM Christophe de Dinechin
<dinechin@redhat.com> wrote:
> On 2021-07-07 at 01:31 UTC, "Adams, Eric" <eric.adams@intel.com> wrote...
> > Christophe,
> > 2) I also observed that Pod Overhead isn't used in the calculation for
> > hotplugged CPU's.
>
> That seems correct. The pod overhead accounts for the overhead "outside" the
> VM, i.e. virtiofsd, qemu's own memory needs, the extra cost of doing I/Os,
> etc. So this is additional resources the host needs, not the VM.

This is very counter-intuitive and also doesn't fit the 'Motivation'
section in the original
design[1]. Wouldn't this lead to wrong results for the resource quota
and scheduler calculations?


Hey Jens,

We add an extra vCPU already to start (default vCPU) in the VM, so I see that as an 'overhead', but not tied to the kubernetes concept "pod overhead". This is just a thread running on the host, and is constrained by the overall pod cgroup. 

Pod Overhead is to ensure the pod cgroup is sized to make room for "the overheads" associated with running a pod. For us that includes the VMM, IO threads, virtiofsd,  the shim, the guest kernel, the guest-agent, etc. Similarly, it is then accounted for in context of eviction, scheduling (predication + prioritization), as well as resource quota management (as you point out). 

I think that's all a bit orthogonal to this discussion. FWIW, we have specific issue in place already to cover the unbound limit portion of this: https://github.com/kata-containers/kata-containers/issues/2071

-Eric
 
[1] https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead

regards
Jens


_______________________________________________
kata-dev mailing list
kata-dev@lists.katacontainers.io
http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev