Re: [PATCH v2] sched: Don't try to catch up excess steal time.

[David Woodhouse]

On Wed, 2024-09-25 at 09:24 -0400, Joel Fernandes wrote:
> > 
> > In
> > https://lore.kernel.org/all/20240522001817.619072-22-dwmw2@xxxxxxxxxxxxx/
> > I put a limit on the amount of steal time carried forward from one
> > timeslice to the next, as it was misbehaving when a bad hypervisor
> > reported negative steal time. But I don't think the limit should be
> > zero.
> 
> Yea, this is the solution I was thinking but I don’t see any limits
> to steal time in the current code. That is what Suleiman is trying to
> fix.
> 
> So why dont we cap the maximum steal time accrued any more (I.e. what
> happened to the code in your patch, was it deleted for another
> reason?).
> 

My patch was never merged. It was part of an exploratory RFC series
working on various KVM clock problems, one of which *fixed* the problem
of steal time going backwards in the hypervisor, and that guest patch
was an attempt to work around that bug in existing KVM. I never did
split it out and send it on its own.

> My impression is your old patch is exactly what we need as Suleiman
> is seeing an issue with suspend causing very very long steal times in
> virtual Machines, but I will let him speak for himself.

Attachment: smime.p7s
Description: S/MIME cryptographic signature