On Tue, Oct 21, 2025, Shrikanth Hegde wrote: > > Hi Sean. > Thanks for taking time and going through the series. > > On 10/20/25 8:02 PM, Sean Christopherson wrote: > > On Wed, Sep 10, 2025, Shrikanth Hegde wrote: > > > tl;dr > > > > > > This is follow up of [1] with few fixes and addressing review comments. > > > Upgraded it to RFC PATCH from RFC. > > > Please review. > > > > > > [1]: v2 - > > > https://lore.kernel.org/all/[email protected]/ > > > > > > v2 -> v3: > > > - Renamed to paravirt CPUs > > > > There are myriad uses of "paravirt" throughout Linux and related > > environments, > > and none of them mean "oversubscribed" or "contended". I assume Hillf's > > comments > > triggered the rename from "avoid CPUs", but IMO "avoid" is at least somewhat > > accurate; "paravirt" is wildly misleading. > > Name has been tricky. We want to have a positive sounding name while > conveying that these CPUs are not be used for now due to contention, > they may be used again when the contention has gone.
I suspect part of the problem with naming is the all-or-nothing approach itself. There's a _lot_ of policy baked into that seemingly simple decision, and thus it's hard to describe with a human-friendly name. > > > Open issues: > > > > > > - Derivation of hint from steal time is still a challenge. Some work is > > > underway to address it. > > > > > > - Consider kvm and other hypervsiors and how they could derive the hint. > > > Need inputs from community. > > > > Bluntly, this series is never going to land, at least not in a form that's > > remotely > > close to what is proposed here. This is an incredibly simplistic way of > > handling > > overcommit, and AFAICT there's no line of sight to supporting more complex > > scenarios. > > > > Could you describe these complex scenarios? Any setup where "don't use this CPU" isn't a viable option, e.g. because all cores could be overcommitted at any given time, or is far, far too coarse-grained. Very few use cases can distill vCPU scheduling needs and policies into single flag. E.g. if all CPUs in a system are being used to vCPU tasks, all vCPUs are actively running, and the host has a non-vCPU task that _must_ run, then the host will need to preempt a vCPU task. Ideally, a paravirtualized scheduling system would allow the host to make an informed decision when choosing which vCPU to preempt, e.g. to minimize disruption to the guest(s).
