On Wed, Feb 07, 2018 at 09:35:04PM -0800, Mike Larkin wrote: > On Thu, Feb 08, 2018 at 04:32:29PM +1300, Jonathan Matthew wrote: > > This diff (most of which has been around for a while) changes delay_func > > when running in KVM to use pvclock (effectively the TSC) to determine when > > to > > stop spinning. Since this is done in a KVM-specific driver, it won't have > > any effect anywhere other than in KVM guests. > > > > Using pvclock rather than the lapic avoids the hangs caused by KVM's use of > > the VMX preemption timer to emulate a lapic. To summarise that problem: > > occasionally KVM fails to restart the lapic timer until it gets an exit from > > the guest, and if we're busy polling the lapic, we'll never generate such an > > exit, and the lapic counter will never reach the value we're waiting for, at > > which point we're stuck. > > > > It also adds a timecounter based on pvclock, with its priority set below > > acpihpet, so it won't be used for now. Later on I'd like to make this > > the preferred timecounter as it's much faster to read than the emulated > > acpihpet. > > > > A couple of testers have confirmed that this does *not* fix the time > > slowdowns > > seen on KVM guests. I believe fixing that will require more invasive > > changes. > > > > Since this fixes a concrete problem, rather than just making me feel better > > about doing lots of clock reads in some other work I'm doing, I'd like to > > get > > this in now. > > > > ok? > > > > After discussing this with jmatthew@ offline, I understand what he's trying to > do here, and I withdraw the earlier objection. > > Some comments: > > 1. does this need special treatment in RAMDISK?
I'll double check that it works on ramdisks before committing, but it should work the same way there as GENERIC. > > 2. can you add a man page for kvmclock(4) and describe what it's for (and > summarize why it's desirable on kvm)? sure. > > 3. do you want to include this in i386? is it even an issue there? i386 has the same lapic code, so it'll hang the same way as amd64, and it can benefit from better timecounters too. I've tested this on i386 and it works there. > > other than those things, ok mlarkin thanks for taking a look.
