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

David Woodhouse
2024-09-25T14:03:05Z

[-- Attachment #1: Type: text/plain, Size: 1226 bytes --]

On Wed, 2024-09-25 at 09:24 -0400, Joel Fernandes wrote:
> >
> > In
> > https://lore.kernel.org/all/20240522001817.619072-22-dwmw2@infradead.org/
> > 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 #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5965 bytes --]