I would lean toward the vendor documentation more than a blog post honestly. Relaxed Co-Scheduling does allow the idle CPU's to have a greater skew by not requiring there always be enough pCPU to schedule every vCPU. The drawback is if you have vCPU's that are always idle, then the skew between the leading vCPU and the trailing vCPU get's to a point where the leading vCPU must be co-stopped to allow the trailing vCPU to catch up. This is important as most operating systems run a tick on each CPU to keep system time and also gauge CPU utilization. When you have vCPU's that are always idle, thanks to Relaxed Co-Scheduling the tick is not scheduled, so the time of return of the tick to the kernel is large, and thus the kernel has no choice but to assume the CPU is being heavily used because these ticks are background priority tasks. Similarly the leading CPU that has to Co-Stop also causes the tick to take a long time to respond, once again making the kernel think the CPU is heavily used.
So while Relaxed Co-Scheduling does allow the vCPU's to become skewed by not requiring every vCPU be scheduled on the host at once, this can lead to both performance increase in some cases but also lead to severe performance degradation because too many vCPU's get assigned to a VM, and the majority of them are idle.
Sincerely,
Jody L. Whitlock
.png "UberGeek1"){kind=avatar}
