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
