Skip to content

vCPUs don't use the full AllowedCPU range when machine-rt/machine-nort slices are configured #908

@eroussy

Description

@eroussy

Describe the bug
I configured machine-rt (resp. machine-nort) slices with an allowed CPU range using cpumachinesrt (resp. cpumachinesnort).
I allowed four hypervisor cores for the non-real-time machine (cpumachinesnort: "9, 10, 25, 26").
I deployed a non-isolated, non-real-time virtual machine.

Even when all four VM cores are heavily used (e.g., by launching a stress-ng command), all four vCPUs of the VM are always scheduled on the first allowed CPU:

root@hypervisor:~# ps -T -o pid,tid,rtprio,pri,psr,comm -p $(pgrep qemu)
PID     TID RTPRIO PRI PSR COMMAND
[...]
2251025 2251073      -  19   9 CPU 0/KVM
2251025 2251074      -  19   9 CPU 1/KVM
2251025 2251075      -  19   9 CPU 2/KVM
2251025 2251076      -  19   9 CPU 3/KVM

To Reproduce

  • Configure cpusystem, cpuuser, cpuovs, cpumachines, cpumachinesrt, cpumachinesnort variables in your inventory (they are all mandatory for the slices to be deployed). Give multiple CPUs to cpumachinesnort.
  • Deploy a non-real-time, non-isolated VM using the SEAPATH guest template.
  • Launch a stress-ng command inside the VM.
  • Observe the vCPU scheduling with ps -T -o pid,tid,rtprio,pri,psr,comm -p $(pgrep qemu).

Expected behavior
vCPUs should switch cores and be scheduled on the rest of the allowed CPUs of the slice.

SEAPATH version
This was tested on SEAPATH Debian trixie.
Ansible is checked out on the old trixie2 branch, but I'm pretty sure it's also the case on the main branch.

Additional context
This is the same root cause as #438.

Metadata

Metadata

Assignees

No one assigned

    Labels

    DebianbugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions