<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 7, 2021 at 1:55 PM Jens Freimann <<a href="mailto:jfreiman@redhat.com" target="_blank">jfreiman@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On Wed, Jul 7, 2021 at 12:48 PM Christophe de Dinechin<br>
<<a href="mailto:dinechin@redhat.com" target="_blank">dinechin@redhat.com</a>> wrote:<br>
> On 2021-07-07 at 01:31 UTC, "Adams, Eric" <<a href="mailto:eric.adams@intel.com" target="_blank">eric.adams@intel.com</a>> wrote...<br>
> > Christophe,<br>
> > 2) I also observed that Pod Overhead isn't used in the calculation for<br>
> > hotplugged CPU's.<br>
><br>
> That seems correct. The pod overhead accounts for the overhead "outside" the<br>
> VM, i.e. virtiofsd, qemu's own memory needs, the extra cost of doing I/Os,<br>
> etc. So this is additional resources the host needs, not the VM.<br>
<br>
This is very counter-intuitive and also doesn't fit the 'Motivation'<br>
section in the original<br>
design[1]. Wouldn't this lead to wrong results for the resource quota<br>
and scheduler calculations?<br>
<br></blockquote><div><br></div><div>Hey Jens,</div><div><br></div><div>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. </div><div><br></div><div>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). </div><div><br></div><div>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: <a href="https://github.com/kata-containers/kata-containers/issues/2071">https://github.com/kata-containers/kata-containers/issues/2071</a></div><div><br></div><div>-Eric</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
[1] <a href="https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead" rel="noreferrer" target="_blank">https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead</a><br>
<br>
regards<br>
Jens<br>
<br>
<br>
_______________________________________________<br>
kata-dev mailing list<br>
<a href="mailto:kata-dev@lists.katacontainers.io" target="_blank">kata-dev@lists.katacontainers.io</a><br>
<a href="http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev" rel="noreferrer" target="_blank">http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev</a><br>
</blockquote></div></div>