Re: [RFC PATCH 0/8] Dynamic vcpu priority management in kvm

[Sean Christopherson]

+sched_ext folks

On Wed, Dec 13, 2023, Vineeth Pillai (Google) wrote:
> Double scheduling is a concern with virtualization hosts where the host
> schedules vcpus without knowing whats run by the vcpu and guest schedules
> tasks without knowing where the vcpu is physically running. This causes
> issues related to latencies, power consumption, resource utilization
> etc. An ideal solution would be to have a cooperative scheduling
> framework where the guest and host shares scheduling related information
> and makes an educated scheduling decision to optimally handle the
> workloads. As a first step, we are taking a stab at reducing latencies
> for latency sensitive workloads in the guest.
> 
> This series of patches aims to implement a framework for dynamically
> managing the priority of vcpu threads based on the needs of the workload
> running on the vcpu. Latency sensitive workloads (nmi, irq, softirq,
> critcal sections, RT tasks etc) will get a boost from the host so as to
> minimize the latency.
> 
> The host can proactively boost the vcpu threads when it has enough
> information about what is going to run on the vcpu - fo eg: injecting
> interrupts. For rest of the case, guest can request boost if the vcpu is
> not already boosted. The guest can subsequently request unboost after
> the latency sensitive workloads completes. Guest can also request a
> boost if needed.
> 
> A shared memory region is used to communicate the scheduling information.
> Guest shares its needs for priority boosting and host shares the boosting
> status of the vcpu. Guest sets a flag when it needs a boost and continues
> running. Host reads this on next VMEXIT and boosts the vcpu thread. For
> unboosting, it is done synchronously so that host workloads can fairly
> compete with guests when guest is not running any latency sensitive
> workload.

Big thumbs down on my end.  Nothing in this RFC explains why this should be done
in KVM.  In general, I am very opposed to putting policy of any kind into KVM,
and this puts a _lot_ of unmaintainable policy into KVM by deciding when to
start/stop boosting a vCPU.

Concretely, boosting vCPUs for most events is far too coarse grained.  E.g. boosting
a vCPU that is running a low priority workload just because the vCPU triggered
an NMI due to PMU counter overflow doesn't make sense.  Ditto for if a guest's
hrtimer expires on a vCPU running a low priority workload.

And as evidenced by patch 8/8, boosting vCPUs based on when an event is _pending_
is not maintainable.  As hardware virtualizes more and more functionality, KVM's
visilibity into the guest effectively decreases, e.g. Intel and AMD both support
with IPI virtualization.

Boosting the target of a PV spinlock kick is similarly flawed.  In that case, KVM
only gets involved _after_ there is a problem, i.e. after a lock is contended so
heavily that a vCPU stops spinning and instead decided to HLT.  It's not hard to
imagine scenarios where a guest would want to communicate to the host that it's
acquiring a spinlock for a latency sensitive path and so shouldn't be scheduled
out.  And of course that's predicated on the assumption that all vCPUs are subject
to CPU overcommit.

Initiating a boost from the host is also flawed in the sense that it relies on
the guest to be on the same page as to when it should stop boosting.  E.g. if
KVM boosts a vCPU because an IRQ is pending, but the guest doesn't want to boost
IRQs on that vCPU and thus doesn't stop boosting at the end of the IRQ handler,
then the vCPU could end up being boosted long after its done with the IRQ.

Throw nested virtualization into the mix and then all of this becomes nigh
impossible to sort out in KVM.  E.g. if an L1 vCPU is a running an L2 vCPU, i.e.
a nested guest, and L2 is spamming interrupts for whatever reason, KVM will end
repeatedly boosting the L1 vCPU regardless of the priority of the L2 workload.

For things that aren't clearly in KVM's domain, I don't think we should implement
KVM-specific functionality until every other option has been tried (and failed).
I don't see any reason why KVM needs to get involved in scheduling, beyond maybe
providing *input* regarding event injection, emphasis on *input* because KVM
providing information to userspace or some other entity is wildly different than
KVM making scheduling decisions based on that information.

Pushing the scheduling policies to host userspace would allow for far more control
and flexibility.  E.g. a heavily paravirtualized environment where host userspace
knows *exactly* what workloads are being run could have wildly different policies
than an environment where the guest is a fairly vanilla Linux VM that has received
a small amount of enlightment.

Lastly, if the concern/argument is that userspace doesn't have the right knobs
to (quickly) boost vCPU tasks, then the proposed sched_ext functionality seems
tailor made for the problems you are trying to solve.

https://lkml.kernel.org/r/20231111024835.2164816-1-tj%40kernel.org