-
Bug
-
Resolution: Unresolved
-
Blocker
-
None
-
None
-
Quality / Stability / Reliability
-
0.42
-
False
-
-
False
-
None
-
-
Critical
-
None
Description of problem:
When starting a vmi with guaranteed QOS, the resulting virt-launcher pod is very slow. After some analysis, it shows that the cgroups are configured as the following: ``` /<path-to-pod>/<our-container>/cpu.max (1000 100000) /<path-to-pod>/<our-container>/container/cpu.max (max 100000) ``` Which means that the cpu is throttled. The same pod with 4.19 the cgroups: ``` /<path-to-pod>/<our-container>/cpu.max (200000 100000) /<path-to-pod>/<our-container>/container/cpu.max (200000 100000) ```
Version-Release number of selected component (if applicable):
4.20
How reproducible:
Everytime
Steps to Reproduce:
1. Start a vm qith dedicated cpu 2. Look at the cgroups in the node where the pod has been scheduled 3. Try to console the vmi
Actual results:
The vmi is booting very very slow
Expected results:
The vmi booting at normal speed
Additional info:
U/S cri-o issue: https://github.com/cri-o/cri-o/issues/9251 We also noticed a general slowness in the runtime of the CI with provider 1.33. In particular, with 1.32 provider the testsuite takes ~1h30m; against the 4h20m with provider 1.33. My personal suspect is that, even with non guuaranteed QOS, there is something wrong.
- is blocked by
-
OCPBUGS-57388 Guaranteed QOS VMI pod slowness due to CPU throttling
-
- Verified
-