From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [PATCH] xen: always set the sched clock as unstable Date: Fri, 13 Apr 2012 19:39:19 +0100 Message-ID: <4F8872D7.7050507@citrix.com> References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Sheng Yang Cc: "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk , "linux-kernel@vger.kernel.org" , Thomas Gleixner , "Tim (Xen.org)" , Jan Beulich List-Id: xen-devel@lists.xenproject.org On 13/04/12 19:31, Sheng Yang wrote: > On Fri, Apr 13, 2012 at 11:20 AM, David Vrabel > wrote: > > From: David Vrabel > > > The sched clock was considered stable based on the capabilities of the > underlying hardware. This does not make sense for Xen PV guests as: > a) the hardware TSC is not used directly as the clock source; and b) > guests may migrate to hosts with different hardware capabilities. > > It is not clear to me whether the Xen clock source is supposed to be > stable and whether it should be stable across migration. For a clock > source to be stable it must be: a) monotonic; c) synchronized across > CPUs; and c) constant rate. > > There have also been reports of systems with apparently unstable > clocks where clearing sched_clock_stable has fixed problems with > migrated VMs hanging. > > So, always set the sched clock as unstable when using the Xen clock > source. > > Signed-off-by: David Vrabel > > --- > arch/x86/xen/time.c | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c > index 0296a95..8469b5a 100644 > --- a/arch/x86/xen/time.c > +++ b/arch/x86/xen/time.c > @@ -473,6 +473,7 @@ static void __init xen_time_init(void) > do_settimeofday(&tp); > > setup_force_cpu_cap(X86_FEATURE_TSC); > + sched_clock_stable = 0; > > xen_setup_runstate_info(cpu); > xen_setup_timer(cpu); > -- > 1.7.2.5 > > > I really prefer to hide nonstop tsc feature from Xen side, rather than > let Linux kernel to have a condition that "Nonstop TSC feature existed, > but sched_clock_stable=0". I disagree. The decision on whether the clock is stable or not should be in the Xen clock source code. David