linux-kernel - Re: [RFC PATCH v3 00/10] paravirt CPUs and push task for less vCPU preemption

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aPkmdsnG1qsaW3Ro@google.com>
Date: Wed, 22 Oct 2025 11:46:14 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Shrikanth Hegde <sshegde@...ux.ibm.com>
Cc: mingo@...hat.com, peterz@...radead.org, juri.lelli@...hat.com, 
	vincent.guittot@...aro.org, tglx@...utronix.de, yury.norov@...il.com, 
	maddy@...ux.ibm.com, linux-kernel@...r.kernel.org, 
	linuxppc-dev@...ts.ozlabs.org, gregkh@...uxfoundation.org, 
	vschneid@...hat.com, iii@...ux.ibm.com, huschle@...ux.ibm.com, 
	rostedt@...dmis.org, dietmar.eggemann@....com, vineeth@...byteword.org, 
	jgross@...e.com, pbonzini@...hat.com
Subject: Re: [RFC PATCH v3 00/10] paravirt CPUs and push task for less vCPU preemption

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/20250625191108.1646208-1-sshegde@linux.ibm.com/
> > > 
> > > 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).