[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231002211651.GA3774@noisy.programming.kicks-ass.net>
Date: Mon, 2 Oct 2023 23:16:51 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Dongli Zhang <dongli.zhang@...cle.com>,
David Woodhouse <dwmw2@...radead.org>,
Joe Jin <joe.jin@...cle.com>, x86@...nel.org,
kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
pbonzini@...hat.com, tglx@...utronix.de, mingo@...hat.com,
bp@...en8.de, dave.hansen@...ux.intel.com
Subject: Re: [PATCH RFC 1/1] KVM: x86: add param to update master clock
periodically
On Mon, Oct 02, 2023 at 11:06:07PM +0200, Peter Zijlstra wrote:
> On Mon, Oct 02, 2023 at 11:18:50AM -0700, Sean Christopherson wrote:
> > +PeterZ
> >
> > Thomas and Peter,
> >
> > We're trying to address an issue where KVM's paravirt kvmclock drifts from the
> > host's TSC-based monotonic raw clock because of historical reasons (at least, AFAICT),
> > even when the TSC is constant. Due to some dubious KVM behavior, KVM may sometimes
> > re-sync kvmclock against the host's monotonic raw clock, which causes non-trivial
> > jumps in time from the guest's perspective.
> >
> > Linux-as-a-guest demotes all paravirt clock sources when the TSC is constant and
> > nonstop, and so the goofy KVM behavior isn't likely to affect the guest's clocksource,
> > but the guest's sched_clock() implementation keeps using the paravirt clock.
> >
> > Irrespective of if/how we fix the KVM host-side mess, using a paravirt clock for
> > the scheduler when using a constant, nonstop TSC for the clocksource seems at best
> > inefficient, and at worst unnecessarily complex and risky.
> >
> > Is there any reason not to prefer native_sched_clock() over whatever paravirt
> > clock is present when the TSC is the preferred clocksource?
>
> I see none, that whole pv_clock thing is horrible crap.
In fact, I don't really see a reason to ever use pv_clock, even on
non-constant TSC. The sched_clock machinery used on x86 (and ia64 at
some point) reverts to tick-based + 'TSC-with-monotonicity-filter
refinement' once it detects the TSC is crap.
And that should work in a guest too I suppose.
Also, I really should clean all that up -- it's all static_key based,
but I think I can do a saner version with static_call. But that's stuck
somewhere on the eternal todo list.
Powered by blists - more mailing lists