Bug 1295203
| Summary: | Scheduling CPU filter doesn't take the new "thread-per-core" value in consideration | ||
|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | sefi litmanovich <slitmano> |
| Component: | Backend.Core | Assignee: | Jenny Tokar <jtokar> |
| Status: | CLOSED NOTABUG | QA Contact: | meital avital <mavital> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.6.2 | CC: | bugs, dfediuck, mlibra |
| Target Milestone: | ovirt-3.6.6 | Flags: | dfediuck:
ovirt-3.6.z?
rule-engine: planning_ack? rule-engine: devel_ack? rule-engine: testing_ack? |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-03-16 15:14:03 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | SLA | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
sefi litmanovich
2016-01-03 14:03:33 UTC
This was intended behavior since the threads-per-core leverages the simultaneous multithreading. The vCPUs for scheduling are computed as: num_of_sockets * num_of_cores. The vCPUs from the guest perspective are computed as num_of_sockets * num_of_cores * num_of_threads. It is suggested to keep the num_of_threads (guest Threads per Core) set to - 1 for x86 - 1..8 for ppc The default is 1, which is the value used before introducing this configuration. Increase it to explicitly set on or leverage the smt. The CPU topology is not reported consistently from libvirt. On PPC, the threads are set on depending on actual load, means they are recently not always reported - i.e. instead of expected 160 CPUs (20 * 8 threads) we get just 20. In other words, counting guest vthreads during scheduling can lead to underutilization and there would be walk around for it in ovirt. The guest threads-per-core can lead to overutilization but only when explicitly set. For completeness, there's an option Count Threads as Cores. It is related to host threads only and makes probably more sense on x86. When this option is set on, the SMT threads will be reported as cores. *** Bug 1295204 has been marked as a duplicate of this bug. *** The idea here is to check whether the VM can get access to the requested number of fully parallel cores. Your VM: Virtual CPU = 16 virtual_sockets = 2 core_per_socket = 1 threads_per_core = 8 = you require only two physical (fully parallel) cores and allow simulating eight threads to coexist on each. The host has 1_socket * 4_cores_per_socket (* 2_threads_per_core) = four physical cores that guarantee full parallelism Wikipedia states: "Hyper-threading works by duplicating certain sections of the processor—those that store the architectural state—but not duplicating the main execution resources." Threads are not considered to be a fully parallel unit (only one thread can use the bus of the core at any given moment) and that is why the cpu policy unit only compares whether the requested amount of fully parallel real cores is available. You can simulate as many threads on those as you want (within some reasonable limits). You really have two options: 1) If you really require access to full cores, update the virtual topology to use more cores and less threads for the same number of vCPUs 2) If you are ok with threads, use threads |