From mboxrd@z Thu Jan 1 00:00:00 1970 From: Radim Krcmar Subject: Re: What's kvmclock's custom sched_clock for? Date: Fri, 8 Jan 2016 15:13:16 +0100 Message-ID: <20160108141316.GC12375@potion.brq.redhat.com> References: <20160107151810.GA12375@potion.brq.redhat.com> <20160107201043.GA18469@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andy Lutomirski , kvm list To: Marcelo Tosatti Return-path: Received: from mx1.redhat.com ([209.132.183.28]:33462 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755448AbcAHONU (ORCPT ); Fri, 8 Jan 2016 09:13:20 -0500 Content-Disposition: inline In-Reply-To: <20160107201043.GA18469@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: 2016-01-07 18:10-0200, Marcelo Tosatti: > On Thu, Jan 07, 2016 at 04:18:11PM +0100, Radim Krcmar wrote: >> Stable sched clock is quite unrelated to TSC features. KVMs from last >> few years should always give good enough result to allow stable sched >> clock. We wanted realtime guests and realtime linux needs no_hz=full >> that depends on stable sched clock. The result is huge hack. >> >> We'd need to say that migration creates powerful gravity fields to >> faithfully migrate constant/invariant TSC, but stable sched clock >> doesn't have that strict expectations about time. > > Was that supposed to be a joke? Yes, if you mean the first sentence of the second paragraph. (I think that we'll use a different disclaimer when we enable best-effort migration with invariant TSC.)