Due to how throttling seems to be implemented in the kernel, it is safer to provision the limit for the full summa of a container's cpuset, even if it means shared user threads can temporarily overstep their boundaries.
Otherwise we can face the really undesirable scenario of shared threads throttling the low latency exclusive users running on the same cpuset.
This half-way approach mimics current K8s upstream behaviour (we still have a CFS quota for administrative purposes), but sets it to a level where it effectively never will be a problem in this edge-scenario
TL;DR there seems to be a hard choice between letting shared threads throttle their own exclusives within the same, or other shared threads in other containers; this PR changes the former to the latter when mixed allocations are used
Due to how throttling seems to be implemented in the kernel, it is safer to provision the limit for the full summa of a container's cpuset, even if it means shared user threads can temporarily overstep their boundaries. Otherwise we can face the really undesirable scenario of shared threads throttling the low latency exclusive users running on the same cpuset. This half-way approach mimics current K8s upstream behaviour (we still have a CFS quota for administrative purposes), but sets it to a level where it effectively never will be a problem in this edge-scenario
TL;DR there seems to be a hard choice between letting shared threads throttle their own exclusives within the same, or other shared threads in other containers; this PR changes the former to the latter when mixed allocations are used