Re: [PATCH v5 13/24] virt/steal_monitor: Add documentation

[Shrikanth Hegde]

On 6/26/26 2:58 PM, Peter Zijlstra wrote:
> On Thu, Jun 25, 2026 at 06:16:37PM +0530, Shrikanth Hegde wrote:
>
> > +Core idea:
> > +==========
> > +steal time is an indication available today in Guest which shows contention
> > +for underlying physical CPU. Use it as a hint in the guest to fold the
> > +workload to a reduced set of vCPUs. When there is contention, steal time
> > +will show up in all the guests. When each guest honors the hint and folds
> > +the workload to a smaller set of vCPUs(Preferred CPUs), it reduces the
> > +contention and thereby reduces vCPU preemption.
> > +This is achieved without any cross-guest communication.
> > +
> > +Steal monitor driver effectively does:
> > +
> > +1. Periodically computes steal time across the system.
> > +
> > +2. If steal time is greater than high threshold, reduce the number of
> > +   preferred CPUs by 1 core. Ensure at least one core is left always.
> > +   This avoids running into extreme cases.
> > +
> > +3. If steal time is lower or equal to low threshold, increase the
> > +   number of preferred CPUs by 1 core. If preferred is same as active,
> > +   nothing to be done.
> > +
> > +4. Ensure preferred CPUs is always subset of active CPUs.
> > +   On feature disable it is same as active CPUs.
>
>
> So this is very much a co-operative scheme. Perhaps add a few words to
> describe the effect of a non cooperative guest. IIRC the result is not
> worse than the status quo. That is, if one (or more) guests refuse to
> co-operate it will not make things worse, it will just not result in
> improvements, right?

Yes, for the benefits all the guests should enable the feature. If not,
one guest may use more. but if we see overall combined performance,
it should be better than status quo.

I will add a paragraph about it.